Inngangur

Fyrir nokkru síðan fékk ég það verkefni að þróa failover klasa fyrir PostgreSQL, sem starfar í nokkrum gagnaverum tengdum ljósleiðara innan einni borgar og þolir bilun (til dæmis rafmagnsleysi) í einni gagnaver. Sem hugbúnaðurinn sem er ábyrgur fyrir bilanaþoli valdi ég Gangráðsvegna þess að þetta er opinbera lausnin frá RedHat til að búa til failover klasa. Það er gott vegna þess að RedHat veitir stuðning við það og vegna þess að þessi lausn er alhliða (eininga). Með hjálp þess verður hægt að tryggja bilanaþol ekki aðeins PostgreSQL, heldur einnig annarrar þjónustu, annað hvort með því að nota staðlaðar einingar eða búa þær til fyrir sérstakar þarfir.

Þessi ákvörðun vakti eðlilega spurningu: hversu bilunarþolinn verður bilunarklasi? Til að kanna þetta þróaði ég prófunarbekk sem líkir eftir ýmsum bilunum á klasahnútunum, bíður eftir að þjónusta verði endurheimt, endurheimtir bilaða hnútinn og heldur áfram að prófa í lykkju. Þetta verkefni hét upphaflega hapgsql en með tímanum leiddist mér nafnið sem hafði bara eitt sérhljóð. Þess vegna byrjaði ég að hringja í villuþolandi gagnagrunna (og fljóta IP sem bendir á þá) krogan (persóna úr tölvuleik þar sem öll mikilvæg líffæri eru afrituð), og hnútar, klasar og verkefnið sjálft eru tuchanka (plánetan þar sem kroganarnir búa).

Nú hafa stjórnendur leyft opna verkefnið fyrir opinn uppspretta samfélagið undir MIT leyfinu. README verður brátt þýtt á ensku (vegna þess að gert er ráð fyrir að helstu neytendur verði Pacemaker og PostgreSQL forritarar), og ég ákvað að kynna gömlu rússnesku útgáfuna af README (að hluta) í formi þessarar greinar.

Klasar eru settir á sýndarvélar VirtualBox. Alls verða 12 sýndarvélar (alls 36GiB) settar á markað, sem mynda 4 bilunarþolna klasa (mismunandi valkostir). Fyrstu tveir klasarnir samanstanda af tveimur PostgreSQL netþjónum, sem eru staðsettir í mismunandi gagnaverum, og sameiginlegum netþjóni Vitni c sveitartæki (hýst á ódýrri sýndarvél í þriðju gagnaveri), sem leysir óvissu 50% / 50%, gefur einum flokkanna atkvæði þitt. Þriðji þyrpingin í þremur gagnaverum: einn húsbóndi, tveir þrælar, nr sveitartæki. Fjórði þyrpingin samanstendur af fjórum PostgreSQL netþjónum, tveimur í hvert gagnaver: einn meistari, restin eftirlíkingar og notar einnig Vitni c sveitartæki. Sá fjórði þolir bilun á tveimur netþjónum eða einu gagnaveri. Hægt er að stækka þessa lausn í fleiri eftirlíkingar ef þörf krefur.

Nákvæm tímaþjónusta ntpd einnig endurstillt fyrir bilanaþol, en það notar aðferðina sjálfa ntpd (munaðarlaus háttur). Sameiginlegur þjónn Vitni virkar sem miðlægur NTP netþjónn, dreifir tíma sínum til allra klasa og samstillir þar með alla netþjóna sín á milli. Ef Vitni bilar eða einangrast, þá mun einn af klasaþjónunum (innan klasans) byrja að dreifa tíma sínum. Auka skyndiminni HTTP umboð einnig hækkað til Vitni, með hjálp þess hafa aðrar sýndarvélar aðgang að Yum geymslum. Í raun og veru verður þjónusta eins og nákvæmur tími og umboð líklega hýst á sérstökum netþjónum, en í básnum eru þær hýstar á Vitni aðeins til að spara fjölda sýndarvéla og pláss.

Útgáfur

v0. Virkar með CentOS 7 og PostgreSQL 11 á VirtualBox 6.1.

Uppbygging klasa

Allir klasar eru hannaðir til að vera staðsettir í mörgum gagnaverum, sameinaðir í eitt flatt net og verða að þola bilun eða neteinangrun í einni gagnaver. Þess vegna er ómögulegt nota til varnar gegn klofinn heili staðlaða gangráðatækni sem kallast STONITH (Skjótu hinn hnútinn í höfuðið) eða Skylmingar. Kjarni þess: ef hnúðana í þyrpingunni byrjar að gruna að eitthvað sé að einhverjum hnút, hann svarar ekki eða hegðar sér rangt, þá slökkva þeir á honum með valdi í gegnum „ytri“ tæki, til dæmis IPMI eða UPS stjórnkort . En þetta mun aðeins virka í þeim tilvikum þar sem IPMI eða UPS þjónninn heldur áfram að virka ef ein bilun kemur upp. Hér ætlum við að verjast miklu hörmulegri bilun, þegar öll gagnaverið bilar (td missir rafmagn). Og með slíkri synjun, allt stonith-tæki (IPMI, UPS osfrv.) munu heldur ekki virka.

Þess í stað er kerfið byggt á hugmyndinni um ályktun. Allir hnútar hafa rödd og aðeins þeir sem sjá meira en helming allra hnúta geta virkað. Þetta magn „hálft + 1“ er kallað ályktun. Ef ályktun er ekki náð, þá ákveður hnúturinn að hann sé í neteinangrun og verður að slökkva á auðlindum sínum, þ.e. þetta er það sem það er klofna heilavörn. Ef hugbúnaðurinn sem er ábyrgur fyrir þessari hegðun virkar ekki, þá verður varðhundur, til dæmis byggður á IPMI, að vinna.

Ef fjöldi hnúta er jafn (þyrping í tveimur gagnaverum) getur komið upp svokölluð óvissa 50% / 50% (fimmtíu og fimmtíu) þegar neteinangrun skiptir þyrpingunni nákvæmlega í tvennt. Þess vegna, fyrir jafnan fjölda hnúta, bætum við við sveitartæki er kröfulaus púki sem hægt er að ræsa á ódýrustu sýndarvélinni í þriðju gagnaverinu. Hann gefur atkvæði sitt í einn af hlutunum (sem hann sér) og leysir þar með 50%/50% óvissuna. Ég nefndi þjóninn sem sveitartækið verður opnað á Vitni (hugtök frá repmgr, mér líkaði það).

Hægt er að færa tilföng á milli staða, til dæmis frá gölluðum netþjónum yfir í heilbrigða, eða eftir stjórn kerfisstjóra. Svo að viðskiptavinir viti hvar auðlindirnar sem þeir þurfa eru staðsettar (hvar á að tengjast?), fljótandi IP (fljóta IP). Þetta eru IP-tölur sem Pacemaker getur fært um hnúta (allt er á flatu neti). Hver þeirra táknar auðlind (þjónustu) og verður staðsett þar sem þú þarft að tengjast til að fá aðgang að þessari þjónustu (í okkar tilviki, gagnagrunnur).

Tuchanka1 (hringrás með þjöppun)

Uppbygging

Hugmyndin var sú að við erum með marga litla gagnagrunna með lágt álag, þar sem það er óarðbært að halda sérstökum þrælaþjóni í heitum biðham fyrir skrifvarinn viðskipti (það er engin þörf á slíkri sóun á auðlindum).

Hvert gagnaver hefur einn netþjón. Hver þjónn hefur tvö PostgreSQL tilvik (í PostgreSQL hugtökum eru þeir kallaðir klasar, en til að forðast rugling mun ég kalla þá tilvik (í hliðstæðu við aðra gagnagrunna), og ég mun aðeins kalla Pacemaker klasa klasa). Eitt tilvik starfar í masterham og aðeins það veitir þjónustu (aðeins flot IP leiðir til þess). Annað tilvikið virkar sem þræll fyrir seinni gagnaverið og mun aðeins veita þjónustu ef húsbóndi þess mistekst. Þar sem oftast mun aðeins eitt tilvik af tveimur (meistarinn) veita þjónustu (framkvæma beiðnir), eru öll miðlaratilföng fínstillt fyrir skipstjórann (minni er úthlutað fyrir shared_buffers skyndiminni o.s.frv.), en þannig að annað tilvikið hefur einnig nóg fjármagn (þó fyrir óviðunandi rekstur í gegnum skyndiminni skráarkerfisins) ef bilun verður í einni af gagnaverunum. Þrællinn veitir ekki þjónustu (framkvæmir ekki skrifbeiðnir) meðan á venjulegri notkun klasans stendur, þannig að það er ekkert stríð um auðlindir við húsbóndann á sömu vél.

Þegar um tvo hnúta er að ræða er bilunarþol aðeins mögulegt með ósamstilltri afritun, þar sem með samstilltri afritun mun bilun þræls leiða til þess að skipstjórinn stöðvast.

Misbrestur á að verða vitni

Að verða ekki vitni (sveitartæki) Ég mun aðeins íhuga Tuchanka1 þyrpinguna, með öllum hinum mun það vera sama sagan. Ef vitni bregst breytist ekkert í klasaskipulaginu, allt mun halda áfram að virka á sama hátt og það gerði. En sveitin verður 2 af 3, og því mun öll síðari bilun verða banvæn fyrir klasann. Það verður samt að laga það sem fyrst.

Tuchanka1 synjun

Bilun í einu af gagnaverunum fyrir Tuchanka1. Í þessu tilfelli Vitni greiðir atkvæði sínu í annan hnút í öðru gagnaveri. Þar breytist fyrrverandi þræll í húsbónda, þar af leiðandi vinna báðir meistararnir á sama netþjóninum og báðir fljótandi IP-tölur þeirra benda á þá.

Tuchanka2 (klassískt)

Uppbygging

Klassískt kerfi tveggja hnúta. Húsbóndinn vinnur á einum, þrællinn á öðrum. Báðir geta framkvæmt beiðnir (þrællinn er skrifvarinn), þannig að báðar eru bentar á flot IP: krogan2 er meistarinn, krogan2s1 er þrællinn. Bæði húsbóndinn og þrællinn munu hafa umburðarlyndi.

Þegar um tvo hnúta er að ræða er bilunarþol aðeins mögulegt með ósamstilltri afritun, því með samstilltri afritun mun bilun þrælsins leiða til þess að skipstjórinn stöðvast.

Tuchanka2 synjun

Ef eitt af gagnaverunum bilar Vitni atkvæði um þann seinni. Í einu starfandi gagnaverinu verður skipstjórinn hækkaður og báðar fljótandi IP-tölurnar benda á hann: húsbóndann og þrælinn. Auðvitað verður að stilla tilvikið þannig að það hafi nægt fjármagn (tengingarmörk o.s.frv.) til að samþykkja allar tengingar og beiðnir frá master og slave float IP samtímis. Það er, við venjulega notkun ætti það að hafa nægilegt framboð af mörkum.

Tuchanka4 (margir þrælar)

Uppbygging

Nú þegar önnur öfga. Það eru til gagnagrunnar sem fá mikið af skrifvarandi beiðnum (týpískt tilfelli um mikið álagssvæði). Tuchanka4 er ástand þar sem það geta verið þrír eða fleiri þrælar til að sinna slíkum beiðnum, en samt ekki of margir. Með mjög miklum fjölda þræla verður nauðsynlegt að finna upp stigveldisafritunarkerfi. Í lágmarkstilvikinu (á myndinni) er hvor tveggja gagnaver með tvo netþjóna, hver með PostgreSQL dæmi.

Annar eiginleiki þessa kerfis er að það er nú þegar hægt að skipuleggja eina samstillta afritun. Það er stillt til að endurtaka, ef mögulegt er, í annað gagnaver, frekar en í eftirmynd í sama gagnaveri og skipstjórinn. Skipstjóra og hvern þræl er bent á fljótandi IP. Sem betur fer, á milli þræla verður nauðsynlegt að halda jafnvægi á beiðnum einhvern veginn sql proxytd viðskiptavinamegin. Mismunandi gerðir viðskiptavina gætu þurft mismunandi gerðir sql proxy, og aðeins verktaki viðskiptavina vita hver þarf hvaða. Þessa virkni er hægt að útfæra annaðhvort með utanaðkomandi púkku eða af biðlarasafni (tengingarpotti) o.s.frv. Allt þetta fer út fyrir efni bilunargagnagrunnsklasa (failover SQL umboð hægt að útfæra sjálfstætt, ásamt bilanaþoli viðskiptavina).

Tuchanka4 synjun

Ef ein gagnaver (þ.e. tveir netþjónar) bilar, greiðir vitni atkvæði fyrir þann seinni. Þar af leiðandi eru tveir netþjónar í gangi í annarri gagnaverinu: annar er að keyra master og skipstjórans flot IP vísar á hann (til að taka á móti lestur-skrifabeiðnum); og á öðrum þjóninum er þræll sem keyrir með samstilltri afritun, og ein af þrælflot IP-tölvunum bendir á hann (fyrir skrifbeiðnir).

Það fyrsta sem þarf að hafa í huga er að ekki eru allir þrælflot IP-tölur verkamenn, heldur aðeins einn. Og til að vinna með það rétt verður það nauðsynlegt sql proxy vísaði öllum beiðnum á eina fljóta IP-töluna sem eftir er; og ef sql proxy nei, þá geturðu skráð alla float IP þræla aðskilda með kommum í tengislóðinni. Í þessu tilfelli, með libpq tengingin verður við fyrsta starfandi IP, þetta er gert í sjálfvirka prófunarkerfinu. Kannski á öðrum bókasöfnum, til dæmis, JDBC, þetta mun ekki virka og er nauðsynlegt sql proxy. Þetta er gert vegna þess að bannað er að hækka fljótandi IP-tölur fyrir þræla samtímis á einum netþjóni, þannig að þeir dreifast jafnt á milli þrælaþjóna ef þeir eru nokkrir í gangi.

Í öðru lagi: Jafnvel ef um bilun í gagnaveri er að ræða verður samstilltri afritun viðhaldið. Og jafnvel þótt aukabilun komi upp, það er að annar af tveimur netþjónum í gagnaverinu sem eftir er bilar, mun þyrpingin, þó að hann hætti að veita þjónustu, enn geyma upplýsingar um allar skuldbundin viðskipti sem hann hefur gefið staðfestingu á skuldbindingunni fyrir. (Það verða engar upplýsingar um tap ef um aukabilun er að ræða).

Tuchanka3 (3 gagnaver)

Uppbygging

Þetta er þyrping fyrir aðstæður þar sem eru þrjár fullvirkar gagnaver, sem hvert um sig er með fullvirkan gagnagrunnsþjón. Í þessu tilfelli sveitartæki ekki þörf. Ein gagnaver er mönnuð af húsbónda, hin tvö eru mönnuð af þrælum. Afritun er samstillt, tegund ANY (slave1, slave2), það er, viðskiptavinurinn mun fá staðfestingu á skuldbindingu þegar einhver þrælanna er fyrstur til að svara að hann hafi samþykkt skuldbindinguna. Tilföng eru auðkennd með einum fljótandi IP fyrir skipstjóra og tveimur fyrir þræla. Ólíkt Tuchanka4 eru allar þrjár fljótandi IP-tölurnar bilunarþolnar. Til að jafna skrifvarið SQL fyrirspurnir sem þú getur notað sql proxy (með aðskildu bilunarvikmörkum), eða úthlutaðu einum þrælflot-IP til helmings viðskiptavinanna og hinn helminginn á þann seinni.

Tuchanka3 synjun

Ef eitt af gagnaverunum bilar eru tvær eftir. Í einu eru master og flot IP frá skipstjóra hækkuð, í annarri - þrællinn og báðar flot IP IP þrælsins (tilvikið verður að hafa tvöfaldan varasjóð af auðlindum til að samþykkja allar tengingar frá báðum slavflot IPs). Samstillt afritun milli húsbænda og þræla. Einnig mun klasinn vista upplýsingar um framin og staðfest viðskipti (ekkert tap verður á upplýsingum) ef tvö gagnaver verða eyðilögð (ef þeim er ekki eytt samtímis).

Ég ákvað að láta ekki fylgja með nákvæma lýsingu á skráargerð og uppsetningu. Allir sem vilja leika sér geta lesið þetta allt í README. Ég er aðeins að gefa lýsingu á sjálfvirkum prófunum.

Sjálfvirkt prófunarkerfi

Til að prófa bilanaþol klasa með því að líkja eftir ýmsum bilunum hefur verið búið til sjálfvirkt prófunarkerfi. Hleypt af stokkunum með handriti test/failure. Handritið getur tekið sem færibreytur fjölda klasa sem þú vilt prófa. Til dæmis þessi skipun:

test/failure 2 3

mun aðeins prófa annan og þriðja klasann. Ef færibreytur eru ekki tilgreindar verða allir klasar prófaðir. Allir klasar eru prófaðir samhliða og niðurstaðan birtist á tmux spjaldinu. Tmux notar sérstakan tmux netþjón, þannig að hægt er að keyra skriftuna undir sjálfgefna tmux, sem leiðir til hreiðraðs tmux. Ég mæli með því að nota flugstöðina í stórum glugga og með litlu letri. Áður en prófun hefst eru allar sýndarvélar færðar aftur í skyndimynd á þeim tíma sem handritinu lýkur setup.

Flugstöðinni er skipt í dálka í samræmi við fjölda klasa sem verið er að prófa; sjálfgefið (á skjámyndinni) eru fjórir. Ég mun lýsa innihaldi dálkanna með því að nota dæmi Tuchanka2. Spjöldin á skjámyndinni eru númeruð:

1. Próftölfræði er sýnd hér. Dálkar:
   • bilun — heiti prófsins (fall í handritinu) sem líkir eftir biluninni.
   • viðbrögð — reiknaður meðaltími í sekúndum þar sem þyrpingin endurheimti virkni sína. Það er mælt frá upphafi handrits sem líkir eftir bilun þar til þyrpingin endurheimtir virkni sína og getur haldið áfram að veita þjónustu. Ef tíminn er mjög stuttur, til dæmis sex sekúndur (þetta gerist í klösum með nokkrum þrælum (Tuchanka3 og Tuchanka4)), þýðir það að bilunin var á ósamstillta þrælnum og hafði ekki áhrif á frammistöðu á nokkurn hátt; það voru engin þyrpingarstöðurofar.
   • frávik — sýnir dreifingu (nákvæmni) gildisins viðbrögð með því að nota staðalfráviksaðferðina.
   • telja — hversu oft þetta próf var gert.
2. Stutt annál gerir þér kleift að meta hvað þyrpingin er að gera. Númer endurtekningar (prófunar), tímastimpill og heiti aðgerðarinnar birtist. Að keyra of lengi (> 5 mínútur) gefur til kynna vandamál.
3. Hjarta (hjarta) - núverandi tími. Fyrir sjónrænt mat á frammistöðu húsbóndi Núverandi tími er stöðugt skrifaður í töfluna með því að nota flot IP master. Ef vel tekst til birtist niðurstaðan á þessu spjaldi.
4. slá (púls) - „núverandi tími“, sem var áður skráð af handritinu Hjarta að ráða, lesið nú úr þræll í gegnum fljótandi IP þess. Gerir þér kleift að meta sjónrænt frammistöðu þrælsins og afritunar. Í Tuchanka1 eru engir þrælar með fljótandi IP (engir þrælar sem veita þjónustu), en það eru tvö tilvik (DB), svo það verður ekki sýnt hér sláOg Hjarta annað tilvik.
5. Eftirlit með heilsu klasa með því að nota tólið pcs mon. Sýnir uppbyggingu, dreifingu auðlinda yfir hnúta og aðrar gagnlegar upplýsingar.
6. Kerfisvöktun frá hverri sýndarvél í klasanum er sýnd hér. Það geta verið fleiri slíkar spjöld eftir því hversu margar sýndarvélar þyrpingin hefur. Tvö línurit CPU álag (sýndarvélar hafa tvo örgjörva), nafn sýndarvélar, Kerfisálag (sem heitir álagsmeðaltal vegna þess að það er meðaltal yfir 5, 10 og 15 mínútur), vinnslugögn og minnisúthlutun.
7. Ummerki um handritið sem framkvæmir prófun. Ef bilun kemur upp - skyndileg truflun á starfsemi eða endalaus biðlota - hér geturðu séð ástæðuna fyrir þessari hegðun.

Prófun fer fram í tveimur áföngum. Í fyrsta lagi fer handritið í gegnum allar tegundir prófa og velur af handahófi sýndarvél sem á að nota þetta próf á. Síðan er framkvæmt endalaus prófunarlota, sýndarvélarnar og bilunin eru valin af handahófi hverju sinni. Skyndileg lokun á prófunarforritinu (neðsta spjaldið) eða endalaus lykkja af bið eftir einhverju (> 5 mínútur framkvæmdartími fyrir eina aðgerð, þetta sést á rekstrinum) gefur til kynna að sum prófin á þessum klasa hafi mistekist.

Hvert próf samanstendur af eftirfarandi aðgerðum:

1. Ræstu aðgerð sem líkir eftir bilun.
2. Tilbúinn? — að bíða eftir að þyrpingin verði endurheimt (þegar öll þjónusta er veitt).
3. Sýnir tímamörk fyrir endurheimt klasans (viðbrögð).
4. Festa — verið er að „gera við“ klasann. Eftir það ætti það að fara aftur í fullkomið starf og vera tilbúið fyrir næstu bilun.

Hér er listi yfir próf með lýsingu á því sem þau gera:

• ForkBomb: Býr til „Out of memory“ með því að nota gaffalsprengju.
• OutOfSpace: Harði diskurinn er fullur. En prófið er frekar táknrænt; með óverulegu álagi sem myndast við prófun, bilar PostgreSQL venjulega ekki þegar harði diskurinn er fullur.
• Postgres-DREPA: drepur PostgreSQL með skipuninni killall -KILL postgres.
• Postgres-STOPP: hangir PostgreSQL skipun killall -STOP postgres.
• Slökkva á: „afvirkjar“ sýndarvélina með skipuninni VBoxManage controlvm "виртуалка" poweroff.
• Endurstilla: ofhleður sýndarvélina með skipuninni VBoxManage controlvm "виртуалка" reset.
• SBD-STOPP: stöðvar SBD púkann með skipuninni killall -STOP sbd.
• Lokun: sendir skipun til sýndarvélarinnar í gegnum SSH systemctl poweroff, kerfið slokknar þokkalega.
• Aftengja: net einangrun, skipun VBoxManage controlvm "виртуалка" setlinkstate1 off.

Ljúka prófunum annað hvort með því að nota venjulegu tmux skipunina „kill-window“ Ctrl-b &, eða "detach-client" skipunina Ctrl-b d: á þessum tímapunkti lýkur prófun, tmux lokar, sýndarvélar eru slökktar.

Vandamál sem komu fram við prófun

• Á þessari stundu varðhundspúki sbd vinnur að því að stöðva púka sem fylgst hefur verið með, en ekki frysta þá. Og þar af leiðandi bilanir sem leiða til frystingar eingöngu Corosync и Gangráðs, en ekki hangandi sbd... Til athugunar Corosync hefur þegar PR#83 (á GitHub kl sbd), samþykkt á þráðinn húsbóndi. Þeir lofuðu (í PR#83) að það yrði eitthvað svipað fyrir Pacemaker, ég vona að kl 8 geri það. En slíkar „bilanir“ eru íhugandi og auðvelt er að líkja eftir þeim á tilbúnar hátt með því að nota td. killall -STOP corosync, en hittist aldrei í raunveruleikanum.

• У Gangráðs í útgáfunni fyrir CentOS 7 rangt stillt sync_timeout у sveitartækifyrir vikið ef einn hnút mistókst, með einhverjum líkindum endurræsti seinni hnúturinn einnig, sem húsbóndinn átti að flytja til. Læknir með stækkun sync_timeout у sveitartæki meðan á dreifingu stendur (í handriti setup/setup1). Þessi breyting var ekki samþykkt af framkvæmdaraðilum Gangráðs, í staðinn lofuðu þeir að endurhanna innviðina á þann hátt (í einhverri ótilgreindri framtíð) að þessi tími yrði reiknaður sjálfkrafa.

• Ef gagnagrunnsstillingin tilgreinir það LC_MESSAGES (textaskilaboð) Unicode má nota, t.d. ru_RU.UTF-8, síðan við ræsingu postgres í umhverfi þar sem staðsetningin er ekki UTF-8, segjum í tómu umhverfi (hér gangráð+pgsqlms(paf) hleypur postgres) Þá login mun innihalda spurningamerki í stað UTF-8 bókstafa. PostgreSQL forritararnir hafa ekki komist að samkomulagi um hvað eigi að gera í þessu tilfelli. Það kostar, þú þarft að setja upp LC_MESSAGES=en_US.UTF-8 þegar þú stillir (búar til) gagnagrunnstilvik.

• Ef wal_receiver_timeout er stillt (sjálfgefið er það 60s), þá á PostgreSQL-STOP prófinu á meistaranum í tuchanka3 og tuchanka4 þyrpingunum afritun tengist ekki aftur við nýja meistarann. Afritun þar er samstillt, þannig að ekki aðeins þrællinn hættir, heldur einnig nýi húsbóndinn. Vinnur með því að stilla wal_receiver_timeout=0 þegar PostgreSQL er stillt.

• Einstaka sinnum sá ég eftirmyndun frýs í PostgreSQL í ForkBomb prófinu (minni flæði). Eftir ForkBomb gætu þrælar stundum ekki tengst nýja meistaranum aftur. Ég hef aðeins lent í þessu í tuchanka3 og tuchanka4 þyrpingunum, þar sem meistarinn fraus vegna samstilltar afritunar. Vandamálið fór af sjálfu sér eftir langan tíma (um tvo tíma). Það þarf frekari rannsóknir til að leiðrétta þetta. Einkennin eru svipuð fyrri galla, sem stafar af annarri ástæðu, en með sömu afleiðingum.

Krogan mynd tekin úr deviant Art með leyfi höfundar:

Heimild: www.habr.com