Hyrje

Para një kohë, më është dhënë detyra për të zhvilluar një klaster të qëndrueshëm për PostgreSQL, që funksionon në disa qendra të të dhënave të lidhura me fibra optike brenda një qyteti, dhe që është në gjendje të përballojë dështimin (p.sh., mungesën e energjisë) të një qendre të të dhënave. Si softuer që responsabon për qëndrueshmërinë, kam zgjedhur Pacemaker, sepse është zgjidhja zyrtare nga RedHat për krijimin e klasterëve të qëndrueshëm. Ajo është e mirë sepse RedHat e mbështet atë, dhe sepse kjo zgjidhje është universale (modulare). Nëpërmjet saj, mund të sigurohet qëndrueshmëria jo vetëm për PostgreSQL, por edhe për shërbime të tjera, ose duke përdorur modulet standarde, ose duke krijuar ato për nevojat specifike.

Për këtë zgjidhje ka lindur një pyetje e arsyeshme: sa e qëndrueshme do të jetë klasteri i qëndrueshëm? Për ta hetuar këtë, kam zhvilluar një laborator testimi që imiton dështime të ndryshme në nyjet e klasterit, pret për rikuperimin e funksionalitetit, rikuperon nyjen e dështuar dhe vazhdon testimin në cikël. Fillimisht, ky projekt quhej hapgsql, por me kalimin e kohës më është bërë e mërzitshme emri që kishte vetëm një vigjë. Prandaj, bazat e të dhënave të qëndrueshme (dhe IP-të që tregojnë për to) fillova t’i quaj krogan (një personazh nga një lojë kompjuterike, i cili ka të gjitha organet e rëndësishme të dyfishta), dhe nyjet, klasterët dhe vetë projektin e quajta tuchanka (planeta ku jetojnë kroganët).

Tani udhëheqja ka lejuar hapjen e projektit për komunitetin open source nën licencën MIT. README në një të ardhme të afërt do të përkthehet në anglisht (sepse pritet që konsumatorët kryesorë të jenë zhvilluesit e Pacemaker dhe PostgreSQL), dhe variantin e vjetër në rus të README e kam vendosur ta organizoj (pjesërisht) në formën e këtij artikulli.

Klasterët vendosen në virtualka VirtualBox. Gjithsej do të krijohen 12 virtualka (me një total prej 36GiB), të cilat formojnë 4 klasterë të qëndrueshëm (varianta të ndryshme). Dy klasterët e parë përbëhen nga dy serverë PostgreSQL, të cilët janë vendosur në qendra të ndryshme të të dhënave, dhe një server i përbashkët witness me quorum device (i vendosur në një virtualke të lirë në një qendër të tretë të të dhënave), i cili zgjidh pasigurinë 50%/50%, duke i dhënë votën e tij njërit prej palëve. Klasteri i tretë është në tre qendra të të dhënave: një master, dy skllevër, pa quorum device. Klasteri i katërt përbëhet nga katër serverë PostgreSQL, me dy në çdo qendër të të dhënave: një master, të tjerët replikat, dhe gjithashtu përdor witness me quorum device. Klasteri i katërt mban një dështim të dy serverëve ose një qendre të të dhënave. Kjo zgjidhje mund të shkallëzohet, nëse është e nevojshme, në më shumë replika.

Shërbimi i kohës së saktë ntpd është gjithashtu rikonfiguruar për qëndrueshmëri, por aty është përdorur metoda e vetë ntpd (orphan mode). Serveri i përbashkët witness përmbush rolin e serverit Qendror NTP, duke shpërndarë kohën e tij për të gjithë klasterët, duke sinjalizuar kështu të gjithë serverët midis tyre. Nëse witness dëshmon dështimin ose të izolohet, atëherë një nga serverët e klasterit do të fillojë të shpërndajë kohën e tij (brenda klasterit). Një proxy ndihmës HTTP proxy është gjithashtu ngritur mbi witness, me të cilin virtualkat e tjera kanë qasje në depozitë Yum. Në realitet, shërbime të tilla si koha e saktë dhe proxy, me siguri do të vendosen në serverë të dedikuar, ndërsa në këtë laborator ato janë vendosur në witness vetëm për të kursyer numrin e virtualkave dhe hapësirën.

Versionet

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

Struktura e klasterëve

Të gjithë klasterët janë të destinuar për t'u vendosur në disa qendra të të dhënave, të lidhura në një rrjet të sheshtë dhe duhet të përballojnë dështimin ose izolimin rrjetor të një qendre të të dhënave. Prandaj e pamundur përdorimi për mbrojtje nga split-brain teknologji standarde Pacemaker, e cila quhet STONITH (Shoot The Other Node In The Head) ose fencing. Thelbi i saj: nëse nyjet në klaster fillojnë të dyshojnë se ndonjë nyjë po kalon në vështirësi, nuk përgjigjet ose sillet në mënyrë të papërshtatshme, ato e çactivate atë me anë të pajisjeve "të jashtme", për shembull, kartën kontrolluese IPMI ose UPS. Por kjo do të funksionojë vetëm në rastet kur, në rastin e një dështimi të vetëm të serverit, IPMI ose UPS vazhdojnë të funksionojnë. Këtu planifikohet një mbrojtje nga një dështim shumë më katastrofik, kur të gjithë qendra e të dhënave dështon (p.sh., humbet energjinë). Dhe në një dështim të tillë, të gjitha stonith-pajisjet (IPMI, UPS, etj.) gjithashtu nuk do të funksionojnë.

Në vend të kësaj, ideja themelore e sistemit është koncepti i kvorumit. Të gjitha nyjet kanë një votë, dhe mund të funksionojnë vetëm ato që shohin më shumë se gjysma e të gjitha nyjeve. Ky numër "gjysmë+1" quhet kvorum. Nëse kvorumi nuk arrihet, nyja vendos se është në izolim rrjetor dhe duhet të çaktivizojë burimet e saj, pra kjo është një mbrojtje nga split-brain. Nëse softi që është përgjegjës për këtë sjellje nuk funksionon, atëherë duhet të aktivizohet watchdog, për shembull, bazuar në IPMI.

Nëse numri i nyjeve është çift (klaster në dy qendra të të dhënave), atëherë mund të ndodhë ajo që quhet pasiguri. 50%/50% (pjesa 50-50), kur izolimi rrjetor ndan klasterin saktësisht në dy pjesë. Prandaj, për numrin çift të nyjeve shtohet quorum device — një demon që nuk kërkon burime, i cili mund të ekzekutohet në virtualizimin më të lirë në qendrën e tretë të të dhënave. Ai i jep zërin njërit prej segmenteve (që sheh) dhe kështu zgjidh pasigurinë 50%/50%. Serveri në të cilin do të aktivizohet pajisja e kuorumit e quajta witness (terminologji nga repmgr, më pëlqeu).

Burimet mund të lëvizin nga një vend në tjetrin, për shembull, nga serverat e prishur në ata të funksionshëm, ose me urdhër të administratorëve të sistemit. Për t'u siguruar që klientët e dinë se ku ndodhen burimet që u nevojiten (ku të lidhen?), përdoren IP të lëvizshme (IP të lëvizshme). Këto janë IP që Pacemaker mund t'i zhvendosë midis nyjeve (gjithçka është në një rrjet të sheshtë). Secila prej tyre simbolizon një burim (shërbim) dhe do të jetë aty ku duhet të lidhen për të marrë qasje në këtë shërbim (në rastin tonë, DB).

Tuchanka1 (schemën me shkallëzim)

Struktura

Ideja ishte se kemi shumë baza të dhënash të vogla me ngarkesë të ulët, për të cilat nuk është ekonomike të mbash një server të dedikuar slave në modalitetin hot standby për transaksione read only (nuk ka nevojë për një shpenzim të tillë burimesh).

Në secilën qendër të të dhënave ka nga një server. Në çdo server ka dy instanca PostgreSQL (në terminologjinë PostgreSQL quhen klastere, por për të shmangur konfuzionin do t'i quaj instanca (sipërisht nga analogjia me DB të tjera), ndërsa klastere do të quaj vetëm klasteret e Pacemaker). Një instancë punon në modin master, dhe vetëm ai ofron shërbime (vetëm ai ka float IP). Instanca e dytë punon si slave për qendrën e dytë të të dhënave dhe do të ofrojë shërbime vetëm në rast se masteri i tij dështoi. Duke pasur parasysh se pjesa më e madhe e kohës do të ofrohet vetëm një instancë nga të dy (master), të gjitha burimet e serverit optimizohen për masterin (i caktohet memorie për kesh shared_buffers etj.), por në mënyrë që të mjaftojë gjithashtu për instancën e dytë (pavarësisht se për të do të ketë burime jooptimale përmes keshit të sistemit të skedarëve) në rast të dështimit të një prej qendrave të të dhënave. Slave nuk ofron shërbime (nuk kryen kërkesa read only) gjatë funksionimit normal të klasterit, për të shmangur luftën për burime me masterin në të njëjtin server.

Në rastin e dy nyjeve, disponueshmëria e lartë është e mundur vetëm me replikim asinkron, sepse nëse ndodh një dështim te slave, do të çojë në ndalimin e masterit.

Dështimi i witness

Dështimi i witness (quorum device) do ta shqyrtoj vetëm për klasterin Tuchanka1, me të gjitha të tjerat do të ketë të njëjtën histori. Nëse witness dështon, struktura e klasterit nuk do të ndryshojë, gjithçka do të vazhdojë të funksionojë siç ka funksionuar. Por kuorumi do të bëhet 2 nga 3, dhe për këtë arsye çdo dështim tjetër do të jetë fatal për klasterin. Do të duhet urgent të riparohet.

Dështimi i Tuchanka1

Dështimi i njërit nga qendrat e të dhënave për Tuchanka1. Në këtë rast witness i jep zërin nyjës së dytë në qendrën e dytë të të dhënave. Atje, ish slave shndërrohet në master, si pasoj e kësaj, të dy masterët punojnë në një server dhe në ta tregohet të dy float IP e tyre.

Tuchanka2 (klasike)

Struktura

Skema klasike me dy nyje. Njëri punon si master, tjetri si slave. Të dy mund të kryejnë kërkesa (slave vetëm read only), prandaj të dy tregojnë float IP: krogan2 — për masterin, krogan2s1 — për slavin. Disponueshmëria e lartë do të jetë si për masterin ashtu edhe për slavin.

Në rastin e dy nyjeve, disponueshmëria e lartë është e mundur vetëm me replikim asinkron, sepse nëse ndodh një dështim te slave, do të çojë në ndalimin e masterit.

Dështimi i Tuchanka2

Në rastin e dështimit të njërit nga qendrat e të dhënave witness voton për të dytin. Në qendrën e vetme të funksionimit do të ngrihet masteri, dhe në të do të tregohen të dy float IP: ai master dhe ai slave. Sigurisht, instanca duhet të jetë e konfiguruar në një mënyrë që të kenë mjaft burime (limitet për lidhje etj.) për të pranuar njëkohësisht të gjitha lidhjet dhe kërkesat nga float IP master dhe slave. Kështu që gjatë funksionimit normal duhet të ketë një rezervë të mjaftueshme në limitet.

Tuchanka4 (shumë slave)

Struktura

Kjo është një tjetër ekstrem. Ka baza të dhënash, të cilat kanë shumë kërkesa read-only (rast tipik i një siti me ngarkesë të lartë). Tuchanka4 është situata kur mund të ketë tre ose më shumë slave për të përballuar kërkesat e tilla, por sërish jo shumë. Kur ka një numër shumë të madh slave, do të duhet të krijohet një sistem hierarkik replikimi. Në rastin minimal (në figurë) në secilën nga dy qendrat e të dhënave janë dy servera, secili me nga një instancë PostgreSQL.

Një veçori tjetër e kësaj skeme është se këtu tashmë mund të organizohet një replikim i sinkronizuar. Ajo është e konfiguruar në mënyrë që të replikojë, sa më shumë të jetë e mundur, në një datacenter tjetër dhe jo në një replika në të njëjtin datacenter si master. Në master dhe në çdo skllav tregohet një float IP. Në të vërtetë, mes skllavëve duhet të bëhet balancimi i kërkesave me ndonjë sql proxy, për shembull, në anën e klientit. Klientë të ndryshëm mund të kenë nevoja të ndryshme sql proxy, dhe vetëm zhvilluesit e klientëve e dinë se kush ka nevojë për çfarë. Kjo funksionalitet mund të realizohet si nga një demon të jashtëm, ashtu edhe nga biblioteka e klientit (connection pool), etj. Gjithçka kjo del jashtë temës së klasterit të DB me qëllim përshtatshmërinë ndaj dështimeve (përshtatshmëria SQL proxy mund të realizohet pavarësisht, së bashku me përshtatshmërinë e klientit).

Dështimi i Tuchanka4

Kur një datacenter dështojnë (dmth. dy servera), dëshmitari voton për të dytin. Si rezultat, në datacentin e dytë funksionojnë dy servera: një ka masterin, dhe për të tregohet float IP i masterit (për të pranuar kërkesat read-write); ndërsa në serverin e dytë funksionon një skllav me replikim të sinkronizuar, dhe për të tregohet një nga float IP-të e skllavëve (për kërkesat read only).

E para që duhet të theksohet: float IP skllav do të jetë vetëm një. Dhe për funksionimin e tij të saktë duhet që sql proxy të gjithë kërkesat të redirektohen në float IP-in e mbetur; dhe nëse sql proxy jo, atëherë mund të listohen të gjitha float IP-të e skllavëve me presje në URL për lidhje. Në këtë rast, me libpq lidhja do të jetë me IP-në e parë funksionale, ashtu si është bërë në sistemin e testimit automatik. Mund të ndodhë që në biblioteka të tjera, si JDBC, të mos funksionojë kështu dhe të nevojitet sql proxy. Kjo është bërë për shkak se për float IP për skllavët është vendosur një ndalesë për t'u ngjitur në të njëjtin server në të njëjtën kohë, në mënyrë që ata të shpërndahen në mënyrë të barabartë në serverat skllavë, nëse punojnë disa.

E dyta: edhe në rast dështimi të datacenterit do të ruhet replikimi i sinkronizuar. Dhe madje edhe nëse ndodhet një dështim tjetër, dmth. një nga dy serverat në datacentin e mbetur dështojnë, klusteri do të ndalojë të ofrojë shërbime, por prapë do të ruajë informacionin mbi të gjitha transaksionet e komituara, për të cilat ka dhënë konfirmimin e komitimit (nuk do të ketë humbje informacioni në rast dështimi të dytë).

Tuchanka3 (3 datacentra)

Struktura

Ky është një kluster për situatën kur ka tre datacentra që funksionojnë plotësisht, në secilin prej të cilëve ka një server DB që funksionon plotësisht. Në këtë rast quorum device nuk është e nevojshme. Në një datacenter funksionon masteri, ndërsa në dy të tjera - skllavët. Replikimi është sinkron, lloji ANY (slave1, slave2), domethënë klienti do të marrë një konfirmim të komitimit kur ndonjë nga skllavët përgjigjet i pari, se ka pranuar komitimin. Një float IP i tregon burimet për masterin dhe dy për skllavët. Ndryshe nga Tuchanka4, të tri float IP-të janë të përshtatshme për dështimin. Për balancimin e kërkesave SQL për vetëm leximin mund të përdoren sql proxy (me një qëndrim të veçantë për dështimet), ose t'u caktohet gjysma e klientëve një float IP skllav, ndërsa gjysma tjetër - një tjetër.

Dështimi i Tuchanka3

Kur dështoni një nga datacentra, mbeten dy. Në njërin është ngritur masteri dhe float IP i masterit, në tjetrin - një skllav dhe të dy float IP-të e skllavëve (në instancë duhet të ketë dyfish rezervë për burimet, në mënyrë që të pranojë të gjitha lidhjet nga të dy float IP-të e skllavëve). Ndërmjet masterit dhe skllavit ka një replikim të sinkronizuar. Po ashtu, klusteri do të ruajë informacionin mbi transaksionet e komituara dhe të konfirmuara (nuk do të ketë humbje informacioni) në rast shkatërrimi të dy datacentra (nëse ato nuk shkatërrohen në të njëjtën kohë).

Përshkrimi i detajuar i strukturës së skedarëve dhe implementimit nuk e kam vendosur. Kushdo që do të dëshirojë të lozë, mund ta lexojë të gjithë këtë në README. Unë vetëm ofroj përshkrimin e testimit automatik.

Sistemi i testimit automatik

Për të verifikuar përshtatshmërinë e klustereve me simulimin e defekteve të ndryshme është krijuar një sistem automatizimi. Aktivizohet me skriptin test/failure. Skripti mund të pranojë si parametra numrat e klustereve që dëshirojnë të testohen. Për shembull, ky urdhër:

test/failure 2 3

do të testojë vetëm klusterin e dytë dhe të tretë. Nëse parametrat nuk janë caktuar, atëherë do të testohen të gjitha klustert. Të gjithë klustert testohen paralelisht, dhe rezultati shfaqet në panelin tmux. Tmux përdor një server tmux të dedikuar, kështu që skripti mund të ekzekutohet nga tmux-i default, duke krijuar një tmux të thelluar. Rekomandoj përdorimin e terminalit në një dritare të madhe dhe me një shkronjë të vogël. Para fillimit të testimit, të gjitha virtualet rikthehen në një snapshot në momentin kur skripti përfundon. setup.

Terminali është i ndarë në kolonat e numrit të klasterëve të testuar, me katër prej tyre siç është treguar në screenshot. Do të shpjegoj përmbajtjen e kolonave duke përdorur Tuchanka2 si shembull. Panelet në screenshot janë të numëruara:

Këtu shfaqet statistika për testet. Kolonat:
- failure — emri i testit (funksioni në skript), i cili simulon një defekt.
- reaction — koha mesatare në sekonda, për të cilën klasteri riktheu funksionalitetin e tij. Matet nga fillimi i punës së skriptit që simulon defektin, deri në momentin kur klasteri rikthehet në funksionalitet dhe është në gjendje të vazhdojë të ofrojë shërbime. Nëse koha është shumë e shkurtër, për shembull, gjashtë sekonda (siç ndodh në klasterët me disa skllavë (Tuchanka3 dhe Tuchanka4)), kjo do të thotë se defekti u shfaq në një skllav asinkron dhe nuk ndikoi në funksionimin, nuk kishte ndërrime të gjendjes së klasterit.
- deviation — tregon shpërndarjen (saktësinë) e vlerës reaction duke përdorur metodën e "devijimit standard".
- count — sa herë është kryer ky test.
Një regjistër i shkurtër lejon të vlerësohet se çfarë po bën klasteri në momentin aktual. Shfaqet numri i iteracionit (testit), vula temporale dhe emri i operacionit. Një performancë shumë e gjatë (> 5 minuta) tregon për ndonjë problem.
heart (zemra) — koha aktuale. Për vlerësimin vizual të funksionalitetit të masterit në tabelën e tij shkruhet vazhdimisht koha aktuale duke përdorur IP-në float të masterit. Në rast suksesi, rezultati shfaqet në këtë panel.
beat (pulsi) — "koha aktuale" e cila ishte regjistruar më parë nga skripti heart në master, tani lexuar nga skllavit nëpërmjet IP-së së tij float. Lejon të vlerësohet vizualisht funksionaliteti i skllavit dhe replikimit. Në Tuchanka1 nuk ka skllavë me IP float (nuk ka skllavë që ofrojnë shërbime), por aty ka dy instance (BD), prandaj këtu do të shfaqet jo beat, dhe heart e dyta e instancës.
Monitorimi i gjendjes së klasterit duke përdorur utilitarin pcs mon. Tregon strukturën, shpërndarjen e burimeve në nyje dhe informacion të dobishëm tjetër.
Këtu shfaqet monitorimi sistemor nga secila makinë virtuale të klasterit. Mund të ketë më shumë se kaq — sa më shumë makina virtuale ka në klaster. Dy grafikë CPU Load (në makinat virtuale janë dy procesorë), emri i makinës virtuale, System Load (e quajtur si Load Average, sepse është mesatare për 5, 10 dhe 15 minuta), të dhënat për proceset dhe shpërndarja e memories.
Gjurmimi i skriptit që kryen testimet. Në rast defekti — ndalim të papritur të punës ose një cikli të pafund pritje — këtu mund të shihni shkakun e këtij sjelljeje.

Testimi zhvillohet në dy etapa. Fillimisht, skripti kalon përmes të gjitha llojeve të testeve, duke zgjedhur rastësisht makinën virtuale, të cilës t’i aplikojë këtë test. Më pas kryhet një cikël të pafund testimi, makinën virtuale dhe defekti zgjidhen rastësisht çdo herë. Ndërprerja e papritur e skriptit të testimit (paneli i poshtëm) ose cikli i pafund pritjeje për ndonjë gjë (> 5 minuta koha e ekzekutimit të një operacioni, e cila duket në gjurmim) tregon se ndonjë nga testet në këtë klaster ka dështuar.

Çdo test përbëhet nga operacione të mëposhtme:

Aktivizimi i funksionit që simulojnë defektin.
Ready? — pritja për rikthimin në funksionalitet të klasterit (kur ofrohen të gjitha shërbimet).
Shfaqet koha e pritjes për rikthimin e klasterit (reaction).
Fix — klasteri "po riparot". Pas kësaj, ai duhet të kthehet në një gjendje plotësisht funksionale dhe të gatshëm për defekte të tjera.

Ja lista e testeve me përshkrimin se çfarë bëjnë:

ForkBomb: krijon "Out of memory" me anë të një bombë fork.
OutOfSpace: mbush diskun. Por testi është më shumë simbolik, me ngarkesën e papërfillshme që krijohet gjatë testimit, përgjithësisht nuk ndodhin dështime të PostgreSQL kur disk është i mbushur.
Postgres-KILL: vret PostgreSQL me komandën killall -KILL postgres.
Postgres-STOP: pezullon PostgreSQL me komandën killall -STOP postgres.
PowerOff: "ndalon energjinë" e makinës virtuale me komandën VBoxManage controlvm "virtual machine" poweroff.
Rivendosja: ri-ngre makinën virtuale me komandën VBoxManage controlvm "virtual machine" reset.
SBD-STOP: pezullon demonin SBD me komandën killall -STOP sbd.
ShutDown: dërgon në makinën virtuale komandën systemctl poweroff, sistemi përfundon punën në mënyrë korrekte.
UnLink: izolimi rrjetor, komanda VBoxManage controlvm "virtual machine" setlinkstate1 off.

Përfundimi i testit ndoshta me komandën standarde tmux "kill-window" Ctrl-b &, ose me komandën "detach-client" Ctrl-b d: në këtë rast, testi përfundon, tmux mbyllet, makinat virtuale fikën.

Problemet e identifikuara gjatë testimit

Aktualisht demonin sbd watchdog reaktron në ndalimin e demonëve të monitoruar, por jo në bllokimin e tyre. Dhe, si pasojë, funksionalitetet e papërshtatshme trajtohen që dërgojnë në bllokimin vetëm Corosync dhe Pacemaker, por njëkohësisht pa e pezulluar sbd. Për verifikim Corosync kemi tashmë PR#83 (në GitHub te sbd), miratuar në degën master. Premtuan (në PR#83) se edhe për Pacemaker do të ketë diçka të ngjashme, shpresoj që deri në RedHat 8 do ta bëjnë. Por të tilla 'probleme' janë të teori, lehtë imitohet artificialisht me ndihmën e, për shembull, killall -STOP corosync, por kurrë nuk ndodhin në jetën reale.
Tek Pacemaker në versionin e CentOS 7 është përgatitur gabim sync_timeout u quorum device, si rezultat kur një nyje dështon, me një probabilitet të caktuar, edhe nyja tjetër ri-startohej, në të cilën duhej të kalonte masteri. Era vështirësohet me rritjen sync_timeout u quorum device gjatë implementimit (në skriptin setup/setup1). Kjo korrigjim nuk u pranua nga zhvilluesit Pacemaker, përkundrazi, ata premtuan të riparojnë infrastrukturën në atë mënyrë (në një të ardhme të pacaktuar) që ky timeout të llogaritet automatikisht.
Nëse gjatë konfigurimit të bazës së të dhënave është e specifikuar se në LC_MESSAGES (mesazhe tekstuale) mund të përdoret Unicode, për shembull, ru_RU.UTF-8, atëherë gjatë ekzekutimit postgres në një mjedis ku locale nuk është UTF-8, të paktën në një mjedis të zbrazët (këtu pacemaker+pgsqlms(paf) e fillon postgres), atëherë në log në vend të caracterëve UTF-8 do të ketë shenja pyetje. Zhvilluesit e PostgreSQL nuk arrinin të vendosin se çfarë duhet të bëjnë në këtë rast. Kjo anashkalohet, duhet të vendoset LC_MESSAGES=en_US.UTF-8 gedhe gjatë konfigurimit (krijimit) të instancës së DB.
Nëse është e caktuar wal_receiver_timeout (në mënyrë default është 60s), atëherë gjatë testit PostgreSQL-STOP në master në klasterët tuchanka3 dhe tuchanka4 nuk ka rindërprerje të replikimit në masterin e ri. Replikimi atje është sinkron, kështu që ndalon jo vetëm punëtori, por edhe masteri i ri. Anashkalohet duke vendosur wal_receiver_timeout=0 gjatë konfigurimit të PostgreSQL.
Rastësisht kam vëzhguar pezullimin e replikimit në PostgreSQL gjatë testit ForkBomb (mbingarkimi i memories). Pas ForkBomb ndonjëherë punëtorët mund të mos rindezhen në masterin e ri. Kam hasur diçka të tillë vetëm në klasterët tuchanka3 dhe tuchanka4, ku për shkak të replikimit sinkron, masteri pezullohej. Problemi kalonte vetvetiu, pas një kohe të gjatë (rreth dy orës). Kërkohet hulumtim shtesë për ta rregulluar këtë. Nga simptomat duket si një defekt i mëparshëm, i shkaktuar nga një arsye tjetër, por me pasojat e njëjta.