įvedimas

Prieš kurį laiką gavau užduotį sukurti failų perkėlimo klasterį PostgreSQL, veikiantis keliuose duomenų centruose, sujungtuose optiniu pluoštu viename mieste, ir galintis atlaikyti vieno duomenų centro gedimą (pavyzdžiui, užtemimą). Pasirinkau kaip programinę įrangą, kuri yra atsakinga už atsparumą gedimams Širdies stimuliatoriusnes tai yra oficialus „RedHat“ sprendimas, leidžiantis kurti perkėlimo grupes. Tai gerai, nes RedHat teikia jam palaikymą, ir todėl, kad šis sprendimas yra universalus (modulinis). Jos pagalba bus galima užtikrinti ne tik PostgreSQL, bet ir kitų paslaugų gedimų toleranciją arba naudojant standartinius modulius, arba kuriant juos specifiniams poreikiams.

Šis sprendimas iškėlė pagrįstą klausimą: kiek atsparus gedimams bus perjungimo klasteris? Norėdami tai ištirti, sukūriau bandymų stendą, kuris imituoja įvairius klasterio mazgų gedimus, laukia, kol paslauga bus atkurta, atkuria sugedusį mazgą ir tęsia bandymą cikle. Šis projektas iš pradžių vadinosi hapgsql, bet laikui bėgant man pabodo pavadinimas, kuriame buvo tik viena balsė. Todėl pradėjau skambinti gedimams atspariomis duomenų bazėmis (ir plūduriuojančiu IP, nurodančiomis į jas) krogan (kompiuterinio žaidimo veikėjas, kuriame dubliuojami visi svarbūs organai), o mazgai, klasteriai ir pats projektas tuchanka (planeta, kurioje gyvena kroganai).

Dabar vadovybė leido atidaryti projektą atvirojo kodo bendruomenei pagal MIT licenciją. README netrukus bus išverstas į anglų kalbą (nes tikimasi, kad pagrindiniai vartotojai bus „Pacemaker“ ir „PostgreSQL“ kūrėjai), todėl nusprendžiau pateikti seną rusišką README versiją (iš dalies) šio straipsnio forma.

Klasteriai diegiami virtualiose mašinose VirtualBox. Iš viso bus įdiegta 12 virtualių mašinų (iš viso 36 GiB), kurios sudaro 4 gedimams atsparias grupes (skirtingos parinktys). Pirmieji du klasteriai susideda iš dviejų PostgreSQL serverių, kurie yra skirtinguose duomenų centruose, ir bendro serverio liudytojas c kvorumo įrenginys (priglobta pigioje virtualioje mašinoje trečiajame duomenų centre), o tai išsprendžia netikrumą 50% / 50%, atiduodami savo balsą vienai iš šalių. Trečiasis klasteris trijuose duomenų centruose: vienas pagrindinis, du pavaldiniai, Nr kvorumo įrenginys. Ketvirtasis klasteris susideda iš keturių „PostgreSQL“ serverių, du kiekviename duomenų centre: vienas pagrindinis, likusios kopijos ir taip pat naudojami liudytojas c kvorumo įrenginys. Ketvirtasis gali atlaikyti dviejų serverių arba vieno duomenų centro gedimą. Jei reikia, šis sprendimas gali būti padidintas iki didesnio kopijų skaičiaus.

Tikslus laiko aptarnavimas ntpd taip pat perkonfigūruotas atsparumui gedimams, tačiau jis naudoja patį metodą ntpd (našlaičių režimas). Bendrinamas serveris liudytojas veikia kaip centrinis NTP serveris, paskirstantis savo laiką visoms grupėms ir taip sinchronizuojantis visus serverius tarpusavyje. Jeigu liudytojas sugenda arba tampa izoliuotas, tada vienas iš klasterio serverių (klasteryje) pradės paskirstyti savo laiką. Pagalbinis talpyklos kaupimas HTTP proxy taip pat pakeltas į liudytojas, su jo pagalba kitos virtualios mašinos turi prieigą prie Yum saugyklų. Tiesą sakant, tokios paslaugos kaip tikslus laikas ir tarpiniai serveriai greičiausiai bus talpinami skirtuose serveriuose, bet kabinoje, kurioje jie yra liudytojas tik norint sutaupyti virtualių mašinų ir vietos.

Versijos

v0. Veikia su CentOS 7 ir PostgreSQL 11 VirtualBox 6.1.

Klasterio struktūra

Visi klasteriai suprojektuoti taip, kad būtų išdėstyti keliuose duomenų centruose, sujungti į vieną plokščią tinklą ir turi atlaikyti vieno duomenų centro gedimus arba tinklo izoliaciją. Štai kodėl neįmanoma naudoti apsaugai nuo suskaidytos smegenys vadinama standartine širdies stimuliatoriaus technologija STONITAS (Šaudyti kitą mazgą į galvą) arba tvoros. Jo esmė: jei klasterio mazgai pradeda įtarti, kad su kokiu nors mazgu kažkas negerai, jis nereaguoja arba elgiasi netinkamai, tada priverstinai jį išjungia per „išorinius“ įrenginius, pavyzdžiui, IPMI ar UPS valdymo kortelę. . Tačiau tai veiks tik tais atvejais, kai įvykus vienam gedimui IPMI arba UPS serveris ir toliau veiks. Čia planuojame apsisaugoti nuo kur kas katastrofiškesnio gedimo, kai sugenda visas duomenų centras (pavyzdžiui, dingsta maitinimas). O su tokiu atsisakymu – viskas stonis-įrenginiai (IPMI, UPS ir kt.) taip pat neveiks.

Vietoj to, sistema yra pagrįsta kvorumo idėja. Visi mazgai turi balsą ir gali veikti tik tie, kurie mato daugiau nei pusę visų mazgų. Šis dydis „pusė + 1“ vadinamas kvorumas. Jeigu nepasiekiamas kvorumas, tai mazgas nusprendžia, kad yra tinklo izoliacijoje ir turi išjungti savo resursus, t.y. štai kas yra apsauga nuo suskaidytų smegenų. Jei programinė įranga, atsakinga už šį elgesį, neveikia, tada, pavyzdžiui, IPMI pagrindu veikiantis šuo turi veikti.

Jei mazgų skaičius yra lygus (klasteris dviejuose duomenų centruose), gali atsirasti vadinamasis neapibrėžtumas 50% / 50% (penkiasdešimt penkiasdešimt), kai tinklo izoliacija padalija klasterį tiksliai per pusę. Todėl lyginiam mazgų skaičiui pridedame kvorumo įrenginys yra nereiklus demonas, kurį galima paleisti pigiausioje virtualioje mašinoje trečiajame duomenų centre. Jis atiduoda savo balsą vienam iš segmentų (kurį mato) ir taip išsprendžia 50 %/50 % neapibrėžtumą. Pavadinau serverį, kuriame bus paleistas kvorumo įrenginys liudytojas (terminologija iš repmgr, man patiko).

Išteklius galima perkelti iš vienos vietos į kitą, pavyzdžiui, iš sugedusių serverių į sveikus arba sistemos administratorių nurodymu. Kad klientai žinotų, kur yra jiems reikalingi ištekliai (kur prisijungti?), plaukiojantis IP (float IP). Tai yra IP, kuriuos širdies stimuliatorius gali perkelti aplink mazgus (viskas yra plokščiame tinkle). Kiekvienas iš jų simbolizuoja išteklius (paslaugą) ir bus ten, kur reikia prisijungti, kad gautumėte prieigą prie šios paslaugos (mūsų atveju duomenų bazės).

Tuchanka1 (grandinė su tankinimu)

Struktūra

Idėja buvo tokia, kad turime daug mažų duomenų bazių su maža apkrova, kurioms neapsimoka išlaikyti dedikuotą verginį serverį karšto budėjimo režimu tik skaitymui (nereikia tokio resursų švaistymo).

Kiekvienas duomenų centras turi vieną serverį. Kiekvienas serveris turi du PostgreSQL egzempliorius (PostgreSQL terminologijoje jie vadinami klasteriais, bet kad nebūtų painiavos, aš juos pavadinsiu egzemplioriais (pagal analogiją su kitomis duomenų bazėmis), o Pacemaker klasterius vadinsiu tik klasteriais). Vienas egzempliorius veikia pagrindiniu režimu ir tik jis teikia paslaugas (į jį veda tik float IP). Antrasis egzempliorius veikia kaip antrojo duomenų centro vergas ir teiks paslaugas tik tuo atveju, jei jo valdiklis suges. Kadangi dažniausiai tik vienas egzempliorius iš dviejų (pagrindinis) teiks paslaugas (vykdys užklausas), visi serverio ištekliai optimizuojami pagrindiniam serveriui (atmintis skiriama share_buffers talpyklai ir pan.), bet taip, kad antrasis egzempliorius taip pat turi pakankamai išteklių (nors ir neoptimaliam veikimui per failų sistemos talpyklą), jei sugestų vienas iš duomenų centrų. Vergas neteikia paslaugų (nevykdo tik skaitymo užklausų) normaliai veikiant klasteriui, kad nebūtų karo dėl išteklių su pagrindiniu toje pačioje mašinoje.

Dviejų mazgų atveju gedimų tolerancija įmanoma tik su asinchroniniu replikavimu, nes sinchroninio replikavimo atveju dėl vergo gedimo bus sustabdytas pagrindinis.

Nesugebėjimas liudyti

Nebuvimas liudytoju (kvorumo įrenginys) Apsvarstysiu tik Tuchanka1 klasterį, su visais kitais bus ta pati istorija. Jei liudytojas nepasiseks, klasterio struktūroje niekas nepasikeis, viskas veiks taip pat, kaip ir toliau. Tačiau kvorumas bus 2 iš 3, todėl bet koks vėlesnis gedimas bus lemtingas klasteriui. Vis tiek teks skubiai taisyti.

Tuchanka1 atsisakymas

Vieno iš Tuchanka1 duomenų centrų gedimas. Tokiu atveju liudytojas balsuoja už antrąjį antrojo duomenų centro mazgą. Ten buvęs vergas virsta šeimininku, dėl to abu šeimininkai dirba tame pačiame serveryje ir abu jų float IP nurodo į juos.

Tuchanka2 (klasikinė)

Struktūra

Klasikinė dviejų mazgų schema. Šeimininkas dirba prie vieno, vergas prie antro. Abu gali vykdyti užklausas (vergas yra tik skaitomas), todėl abu nurodo slankioji IP: krogan2 yra pagrindinis, krogan2s1 yra vergas. Tiek šeimininkas, tiek vergas bus atsparūs gedimams.

Dviejų mazgų atveju gedimų tolerancija įmanoma tik su asinchroniniu replikavimu, nes naudojant sinchroninį replikaciją, pagalbinio įrenginio gedimas sukels pagrindinio įrenginio sustojimą.

Tuchanka2 atsisakymas

Jei vienas iš duomenų centrų sugenda liudytojas balsų už antrąjį. Vieninteliame veikiančiame duomenų centre pagrindinis IP bus pakeltas ir į jį nurodys abu plūduriuojantys IP: pagrindinis ir pavaldinys. Žinoma, egzempliorius turi būti sukonfigūruotas taip, kad jis turėtų pakankamai resursų (ryšių limitų ir pan.), kad vienu metu priimtų visus ryšius ir užklausas iš pagrindinio ir vergo plūduriuojančio IP. Tai reiškia, kad įprasto veikimo metu jis turėtų turėti pakankamai ribų.

Tuchanka4 (daug vergų)

Struktūra

Jau kitas kraštutinumas. Yra duomenų bazių, kurios gauna daug tik skaitymo užklausų (tipiškas didelės apkrovos svetainės atvejis). Tuchanka4 yra situacija, kai gali būti trys ar daugiau vergų, kurie tvarkytų tokius prašymus, bet vis tiek ne per daug. Esant labai dideliam vergų skaičiui, reikės išrasti hierarchinę replikavimo sistemą. Minimaliu atveju (paveikslėlyje) kiekviename iš dviejų duomenų centrų yra du serveriai, kurių kiekvienas turi PostgreSQL egzempliorių.

Dar viena šios schemos ypatybė – jau galima organizuoti vieną sinchroninę replikaciją. Jis sukonfigūruotas taip, kad, jei įmanoma, būtų galima kopijuoti į kitą duomenų centrą, o ne į kopiją tame pačiame duomenų centre kaip ir pagrindinis duomenų centras. Pagrindinis ir kiekvienas vergas yra nukreiptas plūduriuojančiu IP. Laimei, tarp vergų reikės kažkaip subalansuoti prašymus sql tarpinis serveris, pavyzdžiui, kliento pusėje. Įvairių tipų klientams gali prireikti skirtingų tipų sql tarpinis serveris, ir tik klientų kūrėjai žino, kam ko reikia. Šią funkciją gali įgyvendinti išorinis demonas arba kliento biblioteka (ryšių telkinys) ir kt. Visa tai neapsiriboja perteklinės duomenų bazės klasterio tema (perkėlimas SQL tarpinis serveris gali būti įgyvendintas savarankiškai, kartu su kliento gedimų tolerancija).

Tuchanka4 atsisakymas

Jei vienas duomenų centras (t. y. du serveriai) sugenda, liudytojas balsuoja už antrąjį. Dėl to antrajame duomenų centre veikia du serveriai: viename veikia pagrindinis, o pagrindinis float IP nukreipia į jį (skaitymo-rašymo užklausoms priimti); o antrame serveryje yra vergas, veikiantis su sinchroniniu replikavimu, ir vienas iš vergų float IP nurodo į jį (tik skaitomoms užklausoms).

Pirmas dalykas, į kurį reikia atkreipti dėmesį, yra tai, kad ne visi vergų plūduriuojantys IP bus darbuotojai, o tik vienas. Ir norint tinkamai su juo dirbti, to reikės sql tarpinis serveris peradresavo visas užklausas į vienintelį likusį plūduriuojantį IP; ir jeigu sql tarpinis serveris ne, tada ryšio URL galite išvardyti visus plūduriuojančius IP vergus, atskirtus kableliais. Šiuo atveju su libpq prisijungimas bus prie pirmojo veikiančio IP, tai atliekama automatinio testavimo sistemoje. Galbūt kitose bibliotekose, pavyzdžiui, JDBC, tai neveiks ir yra būtina sql tarpinis serveris. Taip daroma, nes slankiuosius IP adresus vergams draudžiama kelti vienu metu viename serveryje, kad jie būtų tolygiai paskirstyti tarp vergų serverių, jei jų veikia keli.

Antra: net duomenų centro gedimo atveju bus palaikoma sinchroninė replikacija. Ir net jei įvyksta antrinis gedimas, ty vienas iš dviejų likusio duomenų centro serverių sugenda, klasteris, nors ir nustos teikti paslaugas, vis tiek išsaugos informaciją apie visas atliktas operacijas, dėl kurių buvo patvirtintas įsipareigojimas. (antrinio gedimo atveju informacijos apie nuostolius nebus).

„Tuchanka3“ (3 duomenų centrai)

Struktūra

Tai klasteris, skirtas situacijai, kai yra trys visiškai veikiantys duomenų centrai, kurių kiekvienas turi pilnai veikiantį duomenų bazės serverį. Tokiu atveju kvorumo įrenginys nereikia. Viename duomenų centre dirba šeimininkas, kituose dviejuose – vergai. Replikacija yra sinchroninė, įveskite ANY (slave1, slave2), tai yra, klientas gaus įsipareigojimo patvirtinimą, kai kuris nors iš vergų pirmasis atsakys, kad jis priėmė įsipareigojimą. Ištekliai žymimi vienu plūduriuojančiu IP pagrindiniam ir dviem pavaldiniams. Skirtingai nuo Tuchanka4, visi trys plūduriuojantys IP yra atsparūs gedimams. Norėdami subalansuoti tik skaitomas SQL užklausas, galite naudoti sql tarpinis serveris (su atskira gedimų tolerancija) arba priskirti vieną pavaldų plūduriuojantį IP pusei klientų, o kitą pusę – antrajam.

Tuchanka3 atsisakymas

Jei vienas iš duomenų centrų sugenda, lieka du. Viename pakeliamas pagrindinis ir plūduriuojantis IP iš pagrindinio, antrame - vergas ir abu vergo plaukiojantys IP (pavyzdys turi turėti dvigubą išteklių rezervą, kad priimtų visus ryšius iš abiejų vergų plūduriuojančių IP). Sinchroninis replikavimas tarp šeimininkų ir vergų. Taip pat klasteris išsaugos informaciją apie įvykdytas ir patvirtintas operacijas (informacija nepraras) sunaikinus du duomenų centrus (jei jie nebus naikinami vienu metu).

Nusprendžiau neįtraukti išsamaus failo struktūros ir diegimo aprašymo. Kiekvienas, norintis pažaisti, gali visa tai perskaityti README. Pateikiu tik automatinio testavimo aprašymą.

Automatinė testavimo sistema

Klasterių atsparumui gedimams patikrinti, imituojant įvairius gedimus, sukurta automatinio testavimo sistema. Paleista pagal scenarijų test/failure. Scenarijus gali priimti kaip parametrus norimų išbandyti grupių skaičių. Pavyzdžiui, ši komanda:

test/failure 2 3

išbandys tik antrą ir trečią klasterį. Jei parametrai nenurodyti, bus tikrinami visi klasteriai. Visi klasteriai yra testuojami lygiagrečiai, o rezultatas rodomas tmux skydelyje. Tmux naudoja tam skirtą tmux serverį, todėl scenarijus gali būti paleistas iš numatytojo tmux, todėl susidaro įdėtas tmux. Rekomenduoju naudoti terminalą dideliame lange ir su mažu šriftu. Prieš pradedant bandymą, visos virtualios mašinos grąžinamos į momentinę kopiją tuo metu, kai scenarijus baigiamas. setup.

Terminalas yra padalintas į stulpelius pagal testuojamų klasterių skaičių, pagal numatytuosius nustatymus (ekrano kopijoje) yra keturi. Stulpelių turinį aprašysiu Tuchanka2 pavyzdžiu. Ekrano kopijoje esančios plokštės yra sunumeruotos:

1. Čia rodoma testų statistika. Stulpeliai:
   • nesėkmė — testo pavadinimas (funkcija scenarijuje), kuris imituoja gedimą.
   • reakcija — aritmetinis vidutinis laikas sekundėmis, per kurį grupė atkūrė savo funkcionalumą. Jis matuojamas nuo scenarijaus, imituojančio gedimą, pradžios iki momento, kai klasteris atkuria savo funkcionalumą ir gali toliau teikti paslaugas. Jei laikas yra labai trumpas, pavyzdžiui, šešios sekundės (tai atsitinka klasteriuose su keliais vergais (Tuchanka3 ir Tuchanka4)), tai reiškia, kad gedimas buvo asinchroniniame verge ir jokiu būdu neturėjo įtakos veikimui; nebuvo klasterio būsenos jungikliai.
   • nuokrypis — parodo vertės sklaidą (tikslumą). reakcija naudojant standartinio nuokrypio metodą.
   • skaičiuoti — kiek kartų šis testas buvo atliktas.
2. Trumpas žurnalas leidžia įvertinti, ką šiuo metu veikia klasteris. Rodomas iteracijos (testo) numeris, laiko žyma ir operacijos pavadinimas. Per ilgas bėgimas (> 5 min.) rodo problemą.
3. širdis (širdis) – dabartinis laikas. Vizualiniam veiklos įvertinimui meistrai Dabartinis laikas nuolat įrašomas į lentelę naudojant plūduriuojančią IP pagrindinę funkciją. Jei pavyks, rezultatas bus rodomas šiame skydelyje.
4. ritmas (pulsas) - „dabartinis laikas“, kuris anksčiau buvo įrašytas scenarijaus širdis įvaldyti, dabar skaitykite nuo vergas per savo plaukiojantį IP. Leidžia vizualiai įvertinti vergo ir replikacijos našumą. Tuchanka1 nėra vergų su plūduriuojančiu IP (jokių paslaugų teikiančių vergų), tačiau yra du atvejai (DB), todėl jis čia nebus rodomas ritmasIr širdis antra instancija.
5. Klasterio būklės stebėjimas naudojant įrankį pcs mon. Rodo struktūrą, išteklių paskirstymą mazguose ir kitą naudingą informaciją.
6. Čia rodomas kiekvienos klasterio virtualios mašinos stebėjimas. Tokių skydelių gali būti ir daugiau, priklausomai nuo to, kiek virtualių mašinų yra klasteryje. Du grafikai CPU apkrova (virtualiose mašinose yra du procesoriai), virtualios mašinos pavadinimas, Sistemos apkrova (vadinamas Apkrovos vidurkiu, nes jis yra vidutiniškai 5, 10 ir 15 minučių), apdoroja duomenis ir atminties paskirstymą.
7. Testavimą atliekančio scenarijaus pėdsakas. Gedimo atveju – staigiai nutrūkus veikimui ar besibaigiančiai laukimo ciklui – čia galite pamatyti tokio elgesio priežastį.

Testavimas atliekamas dviem etapais. Pirma, scenarijus atlieka visų tipų testus, atsitiktinai pasirenkant virtualią mašiną, kuriai taikyti šį testą. Tada atliekamas nesibaigiantis testavimo ciklas, virtualios mašinos ir gedimas kaskart parenkamos atsitiktinai. Staigus testavimo scenarijaus nutraukimas (apatinis skydelis) arba nesibaigiantis kažko laukimo ciklas (> 5 minučių vienos operacijos vykdymo laikas, tai matyti pėdsake) rodo, kad kai kurie šio klasterio bandymai nepavyko.

Kiekvienas testas susideda iš šių operacijų:

1. Paleiskite funkciją, kuri imituoja gedimą.
2. Pasiruošę? — laukiama, kol bus atkurtas klasteris (kai bus suteiktos visos paslaugos).
3. Rodo klasterio atkūrimo skirtąjį laiką (reakcija).
4. nustatyti — klasteris „remontuojamas“. Po to jis turėtų grįžti į visiškai veikiančią būseną ir būti paruoštas kitam gedimui.

Čia yra testų sąrašas su aprašymu, ką jie atlieka:

• ForkBomb: sukuria "Out of memory" naudojant šakės bombą.
• OutOfSpace: Kietasis diskas pilnas. Tačiau testas yra gana simbolinis; dėl nereikšmingos apkrovos, kuri susidaro testavimo metu, PostgreSQL paprastai nesugenda, kai standusis diskas yra pilnas.
• Postgres-KILL: užmuša PostgreSQL su komanda killall -KILL postgres.
• Postgres-STOP: pakimba PostgreSQL komanda killall -STOP postgres.
• Išjungti: komanda „išjungia“ virtualią mašiną VBoxManage controlvm "виртуалка" poweroff.
• naujo: perkrauna virtualią mašiną komanda VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: sustabdo SBD demoną su komanda killall -STOP sbd.
• Išjungti: siunčia komandą į virtualią mašiną per SSH systemctl poweroff, sistema grakščiai išsijungia.
• Atsieti: tinklo izoliacija, komanda VBoxManage controlvm "виртуалка" setlinkstate1 off.

Testavimo užbaigimas naudojant standartinę tmux komandą „kill-window“ Ctrl-b &, arba komanda „detach-client“. Ctrl-b d: šiuo metu testavimas baigiasi, tmux užsidaro, virtualios mašinos išjungiamos.

Bandymo metu nustatytos problemos

• Šiuo momentu sarginis šuo demonas sbd veikia stebimų demonų sustabdymui, bet jų neužšaldymui. Ir dėl to gedimai, dėl kurių tik užšąla Corosync и Širdies stimuliatorius, bet ne kabo sbd... Dėl patikrinimo Corosync jau turi PR#83 („GitHub“ adresu sbd), priimtas į giją meistras. Jie pažadėjo (PR#83), kad bus kažkas panašaus su širdies stimuliatoriumi, tikiuosi, kad iki „RedHat“ 8 padarysiu. Tačiau tokie „gedimai“ yra spekuliatyvūs ir gali būti nesunkiai dirbtinai imituojami naudojant, pavyzdžiui, killall -STOP corosync, bet niekada nesusitiksi realiame gyvenime.

• У Širdies stimuliatorius skirtoje versijoje 7 Centos neteisingai nustatytas sync_timeout у kvorumo įrenginyskaip rezultatas jei vienas mazgas sugedo, su tam tikra tikimybe antrasis mazgas taip pat paleidžiamas iš naujo, į kurią turėjo persikelti meistras. Išgydoma padidinus sync_timeout у kvorumo įrenginys diegimo metu (scenarijus setup/setup1). Šiai pataisai kūrėjai nepritarė Širdies stimuliatorius, vietoj to jie pažadėjo perprojektuoti infrastruktūrą taip (kažkaip nenustatytoje ateityje), kad šis laikas būtų skaičiuojamas automatiškai.

• Jei duomenų bazės konfigūracija tai nurodo LC_MESSAGES (tekstinės žinutės) Galima naudoti Unicode, pvz. ru_RU.UTF-8, tada paleidžiant postgres aplinkoje, kurioje lokalė nėra UTF-8, tarkime, tuščioje aplinkoje (čia širdies stimuliatorius+pgsqlms(paf) bėga postgres) tada žurnale vietoj UTF-8 raidžių bus klaustukai. „PostgreSQL“ kūrėjai nesutarė, ką daryti šiuo atveju. Tai kainuoja, reikia įdiegti LC_MESSAGES=en_US.UTF-8 konfigūruojant (kuriant) duomenų bazės egzempliorių.

• Jei nustatytas wal_receiver_timeout (pagal numatytuosius nustatymus jis yra 60 s), tada atliekant PostgreSQL-STOP testą pagrindiniame įrenginyje tuchanka3 ir tuchanka4 klasteriuose replikacija iš naujo neprisijungia prie naujojo pagrindinio kompiuterio. Replikacija ten yra sinchroninė, todėl sustoja ne tik vergas, bet ir naujasis master. Tai veikia nustatant wal_receiver_timeout=0 konfigūruojant PostgreSQL.

• Kartais „ForkBomb“ teste stebėdavau replikacijos užstrigimą „PostgreSQL“ (atminties perpildymas). Po ForkBomb kartais vergai gali neprisijungti iš naujo prie naujojo pagrindinio. Su tuo susidūriau tik tuchanka3 ir tuchanka4 klasteriuose, kur pagrindinis užstojo dėl sinchroninio replikacijos. Problema išnyko savaime po ilgo laiko (apie dvi valandas). Norint tai ištaisyti, reikia daugiau tyrimų. Simptomai yra panašūs į ankstesnę klaidą, kurią sukelia kita priežastis, bet su tomis pačiomis pasekmėmis.

Krogan nuotrauka daryta iš deviantart su autoriaus leidimu:

Šaltinis: www.habr.com