Esittely

Jokin aika sitten minulle annettiin tehtäväksi kehittää vikasietoklusteri PostgreSQL, joka toimii useissa palvelinkeskuksissa, jotka on yhdistetty optisella kuidulla samassa kaupungissa ja jotka kestävät yhden datakeskuksen vian (esimerkiksi sähkökatkon). Valitsin vikasietoisuudesta vastaavaksi ohjelmistoksi Sydämentahdistin, koska tämä on RedHatin virallinen ratkaisu vikasietoklustereiden luomiseen. Se on hyvä, koska RedHat tukee sitä ja koska tämä ratkaisu on universaali (modulaarinen). Sen avulla on mahdollista tarjota vikasietokykyä PostgreSQL:n lisäksi myös muille palveluille joko vakiomoduuleilla tai luomalla niitä tiettyihin tarpeisiin.

Tämä päätös herätti järkevän kysymyksen: kuinka vikasietoinen vikasietoklusteri on? Tämän tutkimiseksi kehitin testipenkin, joka simuloi erilaisia ​​vikoja klusterin solmuissa, odottaa palvelun palautumista, palauttaa epäonnistuneen solmun ja jatkaa testausta silmukassa. Tämän projektin nimi oli alun perin hapgsql, mutta ajan myötä kyllästyin nimeen, jossa oli vain yksi vokaali. Siksi aloin kutsua vikasietoisia tietokantoja (ja kelluvaa IP-osoitetta, joka osoittaa niihin) krogan (hahmo tietokonepelistä, jossa kaikki tärkeät elimet ovat päällekkäisiä), ja solmut, klusterit ja itse projekti ovat tuchanka (planeetta, jolla kroganit asuvat).

Hallinto on nyt hyväksynyt avaa projekti avoimen lähdekoodin yhteisölle MIT-lisenssillä. README käännetään pian englanniksi (koska Pacemaker- ja PostgreSQL-kehittäjien odotetaan olevan tärkeimmät kuluttajat), ja päätin julkaista README:n vanhan venäläisen version (osittain) tämän artikkelin muodossa.

Klusterit otetaan käyttöön virtuaalikoneissa VirtualBox. Yhteensä 12 virtuaalikonetta (yhteensä 36 GiB) otetaan käyttöön, jotka muodostavat 4 vikasietoklusteria (eri vaihtoehdot). Kaksi ensimmäistä klusteria koostuvat kahdesta PostgreSQL-palvelimesta, jotka sijaitsevat eri tietokeskuksissa, ja yhteisestä palvelimesta Todistaja c päätösvaltainen laite (isännöidään halvalla virtuaalikoneella kolmannessa datakeskuksessa), joka ratkaisee epävarmuuden 50% / 50%, anna äänesi jollekin osapuolelle. Kolmas klusteri kolmessa datakeskuksessa: yksi isäntä, kaksi orjaa, ei päätösvaltainen laite. Neljäs klusteri koostuu neljästä PostgreSQL-palvelimesta, kaksi per datakeskus: yksi isäntä, loput ovat replikoita ja myös Todistaja c päätösvaltainen laite. Neljäs selviää kahden palvelimen tai yhden datakeskuksen epäonnistumisesta. Tätä ratkaisua voidaan tarvittaessa skaalata useampiin replikoihin.

Tarkka aikapalvelu ntpd myös uudelleenkonfiguroitu vikasietoisuuteen, mutta se käyttää itse menetelmää ntpd (orpotila). Jaettu palvelin Todistaja toimii keskeisenä NTP-palvelimena, jakaa aikansa kaikille klusteille ja synkronoi siten kaikki palvelimet keskenään. Jos Todistaja epäonnistuu tai osoittautuu eristetyksi, silloin yksi klusterin palvelimista (klusterin sisällä) alkaa jakaa aikansa. Apuvälimuisti HTTP-välityspalvelin myös korotettu Todistaja, sen avulla muut virtuaalikoneet pääsevät Yum-tietovarastoihin. Todellisuudessa palvelut, kuten tarkka aika ja välityspalvelin, isännöidään todennäköisesti omistetuilla palvelimilla ja kopissa, jossa niitä isännöidään. Todistaja vain virtuaalikoneiden määrän ja tilan säästämiseksi.

versiot

v0. Toimii CentOS 7:n ja PostgreSQL 11:n kanssa VirtualBox 6.1:ssä.

Klusterin rakenne

Kaikki klusterit on suunniteltu sijoitettavaksi useisiin palvelinkeskuksiin, yhdistettynä yhdeksi tasaiseksi verkkoksi, ja niiden on kestettävä yhden datakeskuksen vika tai verkon eristäminen. Siksi on mahdotonta käyttää suojaamiseen jaetut aivot standardi sydämentahdistintekniikkaa kutsutaan STONITH (ammu toinen solmu päähän) tai miekkailu. Sen ydin: jos klusterin solmut alkavat epäillä, että jossakin solmussa on jotain vialla, se ei vastaa tai käyttäytyy väärin, ne sammuttavat sen väkisin "ulkoisten" laitteiden, esimerkiksi IPMI- tai UPS-ohjauskortin, kautta. Mutta tämä toimii vain tapauksissa, joissa IPMI-palvelimen tai UPS:n yksittäisen vian vuoksi ne jatkavat toimintaansa. Se aikoo myös suojautua paljon katastrofaalisemmalta vialta, kun koko palvelinkeskus epäonnistuu (esimerkiksi jännitteetön). Ja sellaisella kieltäytymisellä kaikki stonith-laitteet (IPMI, UPS jne.) eivät myöskään toimi.

Sen sijaan järjestelmä perustuu ajatukseen päätösvaltaisuudesta. Kaikilla solmuilla on ääni, ja vain ne, jotka näkevät yli puolet kaikista solmuista, voivat toimia. Tätä numeroa kutsutaan "puoli + 1". päätösvaltainen. Jos päätösvaltaisuutta ei saavuteta, solmu päättää olevansa verkon eristyksissä ja sammuttaa resurssinsa, ts. tätä se on aivojen jakautumisen suoja. Jos tästä käyttäytymisestä vastuussa oleva ohjelmisto ei toimi, esimerkiksi IPMI-pohjaisen vahtikoiran on toimittava.

Jos solmujen määrä on parillinen (klusteri kahdessa palvelinkeskuksessa), voi syntyä ns. 50% / 50% (puolet ja puolet), kun verkon eristäminen jakaa klusterin tarkalleen puoliksi. Siksi parilliselle määrälle solmuja se lisätään päätösvaltainen laite - vaatimaton demoni, jota voidaan käyttää kolmannen datakeskuksen halvimmalla virtuaalikoneella. Hän antaa äänensä yhdelle segmentistä (jonka hän näkee) ja ratkaisee siten 50 %/50 % epävarmuuden. Soitin palvelimelle, jolla koorumilaite toimii Todistaja (terminologia repmgr:stä, pidin siitä).

Resurssit voivat siirtyä paikasta toiseen, esimerkiksi viallisilta palvelimilta huollettaville palvelimille tai järjestelmänvalvojien käskystä. Jotta asiakkaat tietäisivät, missä heidän tarvitsemansa resurssit sijaitsevat (minne muodostaa yhteyden?), kelluva IP (float IP). Nämä ovat IP-osoitteita, joita Pacemaker voi siirtää solmujen ympäri (kaikki on tasaisessa verkossa). Jokainen niistä symboloi resurssia (palvelua) ja sijoitetaan paikkaan, jossa sinun on muodostettava yhteys päästäksesi tähän palveluun (meidän tapauksessamme tietokanta).

Tuchanka1 (pakattu malli)

Rakenne

Ajatuksena oli, että meillä on monia pieniä, vähän kuormitettuja tietokantoja, joille ei ole kannattavaa ylläpitää dedikoitua orjapalvelinta hot standby -tilassa vain luku -tapahtumia varten (tällaista resurssien tuhlausta ei tarvita).

Jokaisessa palvelinkeskuksessa on yksi palvelin. Jokaisella palvelimella on kaksi PostgreSQL-instanssia (PostgreSQL-terminologiassa niitä kutsutaan klustereiksi, mutta sekaannusten välttämiseksi kutsun niitä ilmentymäksi (analogisesti muiden tietokantojen kanssa), ja kutsun Pacemaker-klustereita vain klustereiksi). Yksi ilmentymä toimii master-tilassa ja vain se tarjoaa palveluita (vain float IP johtaa siihen). Toinen esiintymä toimii orjana toiselle datakeskukselle ja tarjoaa palveluita vain, jos sen isäntä epäonnistuu. Koska useimmiten vain yksi ilmentymä kahdesta (isäntäkone) tarjoaa palveluita (suorittaa pyyntöjä), kaikki palvelinresurssit optimoidaan isäntäkoneelle (muisti on varattu share_buffers-välimuistille jne.), mutta niin, että toinen esiintymä sillä on myös tarpeeksi resursseja (tosinkin epäoptimaaliseen toimintaan tiedostojärjestelmän välimuistin kautta), jos jokin datakeskuksista epäonnistuu. Orja ei tarjoa palveluita (ei suorita vain lukupyyntöjä) klusterin normaalin toiminnan aikana, joten resursseista ei käydä sotaa saman koneen isäntäkoneen kanssa.

Kahden solmun tapauksessa vikasietoisuus on mahdollista vain asynkronisessa replikaatiossa, koska synkronisessa replikaatiossa orjan vika johtaa isäntälaitteen pysähtymiseen.

Todistamatta jättäminen

todistamatta jättäminen (päätösvaltainen laite) Harkitsen vain Tuchanka1-klusteria, kaikkien muiden kanssa se on sama tarina. Jos todistaja epäonnistuu, mikään ei muutu klusterin rakenteessa, kaikki toimii edelleen samalla tavalla kuin toimi. Mutta päätösvaltaisuudesta tulee 2/3, ja siksi kaikki myöhemmät epäonnistumiset ovat kohtalokkaita klusterille. Se pitää vielä korjata pikaisesti.

Hylkääminen Tuchanka1

Vika yhdessä Tuchankan1 palvelinkeskuksista. Tässä tapauksessa Todistaja antaa äänensä toisen datakeskuksen toiselle solmulle. Siellä entisestä orjasta tulee isäntä, minkä seurauksena molemmat isännät työskentelevät samalla palvelimella ja heidän molemmat kelluvat IP-osoitteet osoittavat niihin.

Tuchanka2 (klassinen)

Rakenne

Klassinen kahden solmun kaavio. Isäntä työskentelee yhdellä, orja toisella. Molemmat voivat suorittaa pyyntöjä (orja on vain luku), joten molempiin osoitetaan kelluva IP: krogan2 on isäntä, krogan2s1 on orja. Sekä isännällä että orjalla on vikasietoisuus.

Kahden solmun tapauksessa vikasietoisuus on mahdollista vain asynkronisella replikaatiolla, koska synkronisessa replikaatiossa orjan vika johtaa isäntälaitteen pysähtymiseen.

Hylkääminen Tuchanka2

Jos jokin palvelinkeskuksista epäonnistuu Todistaja ääniä toiselle. Ainoassa toimivassa datakeskuksessa isäntä nostetaan, ja molemmat kelluvat IP-osoitteet osoittavat siihen: isäntä ja orja. Tietenkin ilmentymä on konfiguroitava siten, että sillä on tarpeeksi resursseja (yhteysrajoitukset jne.) hyväksyä samanaikaisesti kaikki yhteydet ja pyynnöt isäntä- ja orja-IP:ltä. Toisin sanoen normaalikäytössä sillä pitäisi olla riittävästi rajoja.

Tuchanka4 (monet orjia)

Rakenne

Jo toinen ääripää. On tietokantoja, jotka vastaanottavat paljon vain luku -pyyntöjä (tyypillinen tapaus korkean kuormituksen sivustolle). Tuchanka4 on tilanne, jossa voi olla kolme tai useampia orjia käsittelemään tällaisia ​​pyyntöjä, mutta ei kuitenkaan liikaa. Kun orjia on erittäin paljon, on välttämätöntä keksiä hierarkkinen replikointijärjestelmä. Vähimmäistapauksessa (kuvassa) kummassakin datakeskuksessa on kaksi palvelinta, joissa kummassakin on PostgreSQL-ilmentymä.

Toinen tämän kaavan piirre on, että täällä on jo mahdollista järjestää yksi synkroninen replikaatio. Se on määritetty replikoimaan, jos mahdollista, toiseen datakeskukseen, ei replikaan, joka on samassa datakeskuksessa kuin isäntä. Isäntä ja jokainen orja osoitetaan kelluvalla IP-osoitteella. Loppujen lopuksi orjien välillä on tarpeen tehdä jonkinlainen pyyntöjen tasapainotus sql-välityspalvelinesimerkiksi asiakkaan puolella. Erilaiset asiakkaat voivat vaatia erilaisia ​​asiakkaita sql-välityspalvelin, ja vain asiakaskehittäjät tietävät, kuka tarvitsee minkä tahansa. Tämä toiminto voidaan toteuttaa joko ulkoisella demonilla tai asiakaskirjastolla (yhteyspooli) jne. Kaikki tämä ei kuulu tietokannan vikasietoklusterin (failover SQL-välityspalvelin voidaan toteuttaa itsenäisesti yhdessä asiakkaan vikasietoisuuden kanssa).

Hylkääminen Tuchanka4

Jos yksi palvelinkeskus (eli kaksi palvelinta) epäonnistuu, todistaja äänestää toisen puolesta. Seurauksena on, että toisessa datakeskuksessa on käynnissä kaksi palvelinta: toinen käyttää isäntäpalvelinta, ja master float IP osoittaa siihen (luku- ja kirjoituspyyntöjen vastaanottamista varten); ja toisella palvelimella on orja käynnissä synkronisella replikaatiolla, ja yksi orja float IP -osoitteesta osoittaa siihen (vain luku -pyynnöille).

Ensimmäinen huomioitava asia on, että kaikki orja-IP:t eivät ole työntekijöitä, vaan vain yksi. Ja työskennelläksesi sen kanssa oikein, se on välttämätöntä sql-välityspalvelin uudelleenohjasi kaikki pyynnöt ainoaan jäljellä olevaan kelluvaan IP-osoitteeseen; ja jos sql-välityspalvelin ei, voit luetella kaikki kelluvat IP-orjat pilkuilla erotettuina yhteyden URL-osoitteessa. Tässä tapauksessa kanssa libpq yhteys muodostetaan ensimmäiseen toimivaan IP-osoitteeseen, tämä tehdään automaattisessa testausjärjestelmässä. Ehkä muissa kirjastoissa, esimerkiksi JDBC:ssä, tämä ei toimi ja on välttämätöntä sql-välityspalvelin. Tämä tapahtuu, koska orjien kelluvien IP-osoitteiden nostaminen samanaikaisesti yhdellä palvelimella on kielletty, jotta ne jakautuvat tasaisesti orjapalvelimien kesken, jos niitä on käynnissä useita.

Toiseksi: synkroninen replikointi säilyy jopa datakeskuksen vian sattuessa. Ja vaikka tapahtuisi toissijainen vika, eli toinen kahdesta palvelimesta epäonnistuu jäljellä olevassa datakeskuksessa, vaikka klusteri lopettaakin palvelujen tarjoamisen, se säilyttää silti tiedot kaikista sitoutuneista tapahtumista, joille se vahvisti sitoumuksen (sisältää ei menetetä tietoja toissijaisesta viasta).

Tuchanka3 (3 palvelinkeskusta)

Rakenne

Tämä on klusteri tilanteeseen, jossa on kolme täysin toimivaa datakeskusta, joista jokaisessa on täysin toimiva tietokantapalvelin. Tässä tapauksessa päätösvaltainen laite ei tarvita. Isäntä toimii yhdessä datakeskuksessa ja orjat kahdessa muussa. Replikointi on synkroninen, tyyppi ANY (slave1, slave2), eli asiakas saa vahvistuksen, kun joku orjista vastaa ensimmäisenä, että hän on hyväksynyt toimituksen. Resursseihin osoitetaan yksi kelluva IP isännälle ja kaksi orjalle. Toisin kuin Tuchanka4, kaikki kolme kelluvaa IP-osoitetta ovat vikasietoisia. Voit käyttää vain luku -tilassa olevien SQL-kyselyjen tasapainottamista sql-välityspalvelin (erillisellä vikasietokyvyllä) tai määritä yksi orja-IP float puolelle asiakkaista ja toinen toiselle puolikkaalle.

Hylkääminen Tuchanka3

Jos yksi palvelinkeskuksista epäonnistuu, kaksi jää jäljelle. Yhdessä nostetaan isäntä ja kelluva IP isännältä, toisessa orja ja molemmat orja float IP:t (instanssissa on oltava kaksinkertainen resurssireservi, jotta kaikki yhteydet voidaan hyväksyä molemmilta orja-IP:iltä). Synkroninen replikointi isäntien ja orjien välillä. Lisäksi klusteri tallentaa tiedot sitoutuneista ja vahvistetuista tapahtumista (tietoja ei menetetä), jos kaksi datakeskusta tuhoutuu (jos niitä ei tuhota samanaikaisesti).

Päätin olla sisällyttämättä yksityiskohtaista kuvausta tiedostorakenteesta ja käyttöönotosta. Jokainen, joka haluaa leikkiä, voi lukea kaiken README:stä. Annan vain kuvauksen automaattisesta testauksesta.

Automaattinen testausjärjestelmä

Klusterien vikasietoisuuden testaamiseksi erilaisia ​​vikoja simuloimalla on luotu automaattinen testausjärjestelmä. Käynnistetty käsikirjoituksella test/failure. Skripti voi ottaa parametreiksi klusterien lukumäärän, jotka haluat testata. Esimerkiksi tämä komento:

test/failure 2 3

testaa vain toista ja kolmatta klusteria. Jos parametreja ei ole määritetty, kaikki klusterit testataan. Kaikki klusterit testataan rinnakkain ja tulos näkyy tmux-paneelissa. Tmux käyttää omistettua tmux-palvelinta, joten komentosarjaa voidaan ajaa oletus-tmuxin alta, jolloin tuloksena on sisäkkäinen tmux. Suosittelen käyttämään päätettä suuressa ikkunassa ja pienellä fontilla. Ennen testauksen aloittamista kaikki virtuaalikoneet palautetaan tilannekuvaksi komentosarjan päättyessä setup.

Pääte on jaettu sarakkeisiin testattavien klustereiden määrän mukaan, oletusarvoisesti (kuvakaappauksessa) niitä on neljä. Kuvaan sarakkeiden sisältöä Tuchanka2:n esimerkillä. Kuvakaappauksen paneelit on numeroitu:

1. Tässä näytetään testitilastot. Kaiuttimet:
   • vika — sen testin nimi (skriptin funktio), joka emuloi vikaa.
   • reaktio — aritmeettinen keskimääräinen aika sekunteina, jonka ajan klusteri on palauttanut toimintansa. Se mitataan virhettä emuloivan skriptin alusta siihen hetkeen asti, jolloin klusteri palauttaa toimintakuntonsa ja pystyy jatkamaan palveluiden tarjoamista. Jos aika on hyvin lyhyt, esimerkiksi kuusi sekuntia (tämä tapahtuu klustereissa, joissa on useita orjia (Tuchanka3 ja Tuchanka4)), tämä tarkoittaa, että vika päätyi asynkroniseen orjaan eikä vaikuttanut suorituskykyyn millään tavalla, ei ollut klusterin tilakytkimet.
   • poikkeama - näyttää arvon leviämisen (tarkkuuden). reaktio käyttäen standardipoikkeamamenetelmää.
   • laskea Kuinka monta kertaa tämä testi on tehty.
2. Lyhyen lokin avulla voit arvioida, mitä klusteri tällä hetkellä tekee. Iteration (testin) numero, aikaleima ja toiminnon nimi näytetään. Liian pitkä juoksu (> 5 minuuttia) on merkki ongelmasta.
3. sydän (sydän) on nykyinen aika. Suorituksen visuaaliseen arviointiin isäntä Nykyinen aika kirjoitetaan jatkuvasti sen taulukkoon float IP-masterilla. Jos onnistut, tulos näkyy tässä paneelissa.
4. lyödä (pulssi) - "nykyinen aika", jonka käsikirjoitus on aiemmin tallentanut sydän hallita, lue nyt alkaen orja kelluvan IP-osoitteen kautta. Voit arvioida visuaalisesti orjan ja replikoinnin suorituskykyä. Tuchanka1:ssä ei ole orjia, joilla on float IP (ei ole palveluita tarjoavia orjia), mutta esiintymiä on kaksi (DB), joten sitä ei näytetä tässä lyödäJa sydän toinen oikeusaste.
5. Seurataan klusterin tilaa apuohjelman avulla pcs mon. Näyttää rakenteen, resurssien jakautumisen solmuittain ja muuta hyödyllistä tietoa.
6. Se näyttää järjestelmän valvonnan jokaisesta klusterin virtuaalikoneen. Tällaisia ​​paneeleja voi olla enemmän - kuinka monta virtuaalikoneita klusterissa on. Kaksi kaaviota Suorittimen kuormitus (virtuaalikoneissa on kaksi prosessoria), virtuaalikoneen nimi, Järjestelmän kuormitus (nimeltään Load Average, koska sen keskiarvo oli 5, 10 ja 15 minuuttia), prosessitiedot ja muistin varaus.
7. Testit suorittavan skriptin jäljittäminen. Toimintahäiriön sattuessa - äkillinen työn keskeytys tai loputon odotussykli - näet tästä syyn.

Testaus suoritetaan kahdessa vaiheessa. Ensin komentosarja käy läpi kaiken tyyppiset testit ja valitsee satunnaisesti virtuaalikoneen, johon tätä testiä sovelletaan. Sitten suoritetaan loputon testaussykli, virtuaalikoneet ja vika valitaan joka kerta satunnaisesti. Testausskriptin äkillinen lopettaminen (alapaneeli) tai loputon silmukka odottamassa jotakin (> 5 minuutin suoritusaika yhdelle toimenpiteelle, tämä näkyy jäljessä) osoittaa, että jotkut tämän klusterin testeistä ovat epäonnistuneet.

Jokainen testi koostuu seuraavista toiminnoista:

1. Käynnistä toiminto, joka jäljittelee vikaa.
2. Oletko valmis? — odottaa klusterin palauttamista (kun kaikki palvelut tarjotaan).
3. Näyttää klusterin palautuksen aikakatkaisun (reaktio).
4. Korjata - klusteria "korjataan". Sen jälkeen sen pitäisi palata täysin toimintatilaan ja olla valmis seuraavaan toimintahäiriöön.

Tässä on luettelo testeistä ja kuvaus siitä, mitä ne tekevät:

• ForkBomb: Luo "Muisti loppu" haarukkapommilla.
• Tila lopussa: Kiintolevy on täynnä. Mutta testi on melko symbolinen; testauksen aikana syntyvän merkityksettömän kuormituksen vuoksi PostgreSQL ei yleensä epäonnistu, kun kiintolevy on täynnä.
• Postgres-KILL: tappaa PostgreSQL:n komennolla killall -KILL postgres.
• Postgres-STOP: jumittuu PostgreSQL-komento killall -STOP postgres.
• Virta pois: "syöttää" virtuaalikoneen komennolla VBoxManage controlvm "виртуалка" poweroff.
• asettaa uudelleen: ylikuormittaa virtuaalikoneen komennolla VBoxManage controlvm "виртуалка" reset.
• SBD STOP: pysäyttää SBD-demonin komennolla killall -STOP sbd.
• Sammuttaa: lähettää komennon virtuaalikoneeseen SSH:n kautta systemctl poweroff, järjestelmä sammuu sulavasti.
• Poista linkitys: verkon eristys, komento VBoxManage controlvm "виртуалка" setlinkstate1 off.

Testauksen suorittaminen joko tavallisella tmux-komennolla "kill-window" ctrl-b&tai komennolla "detach-client" ctrl-bd: samaan aikaan testaus on valmis, tmux suljetaan, virtuaalikoneet sammutetaan.

Testauksen aikana havaitut ongelmat

• Tällä hetkellä vahtikoiran daemon sbd toimii pysäyttämään havaitut demonit, mutta ei jäädyttämään niitä. Ja seurauksena viat, jotka johtavat vain jäätymiseen Corosync и Sydämentahdistin, mutta ei roikkuu sbd. Tarkistaa varten Corosync on jo PR # 83 (GitHubissa klo sbd), hyväksytty osastolle mestari. He lupasivat (PR#83:ssa), että Pacemakerille olisi jotain vastaavaa, toivottavasti tähän mennessä Redhat xnumx sopii. Mutta tällaiset "häiriöt" ovat spekulatiivisia ja niitä voidaan helposti simuloida keinotekoisesti esim. killall -STOP corosync, mutta koskaan tavata oikeassa elämässä.

• У Sydämentahdistin versiossa for 7 CentOS väärin asetettu sync_timeout у päätösvaltainen laiteseurauksena jos yksi solmu epäonnistui, toinen solmu käynnistyi uudelleen jollain todennäköisyydellä, johon mestarin piti muuttaa. Laajentuneena sync_timeout у päätösvaltainen laite käyttöönoton aikana (skriptissä setup/setup1). Kehittäjät eivät hyväksyneet tätä muutosta Sydämentahdistin, sen sijaan he lupasivat suunnitella infrastruktuurin uudelleen niin (jossain määrittelemättömässä tulevaisuudessa), että tämä aikakatkaisu lasketaan automaattisesti.

• Jos tietokannan kokoonpano määrittää sen LC_MESSAGES (tekstiviestit) Unicodea voidaan käyttää esim. ru_RU.UTF-8, sitten käynnistyksen yhteydessä postgres ympäristössä, jossa alue ei ole UTF-8, vaikkapa tyhjässä ympäristössä (tässä sydämentahdistin+pgsqlms(paf) alkaa postgres) sitten loki sisältää kysymysmerkkejä UTF-8-kirjainten sijaan. PostgreSQL-kehittäjät eivät koskaan sopineet, mitä tehdä tässä tapauksessa. Se maksaa, sinun täytyy laittaa LC_MESSAGES=en_US.UTF-8 kun määrität (luodat) tietokantainstanssia.

• Jos wal_receiver_timeout on asetettu (oletuksena se on 60 s), niin PostgreSQL-STOP-testin aikana isännässä tuchanka3- ja tuchanka4-klustereissa Replikointi ei muodosta yhteyttä uudelleen uuteen pääkoneeseen. Replikointi siellä on synkronista, joten ei vain orja pysähtyy, vaan myös uusi isäntä. Saa asettamalla wal_receiver_timeout=0 PostgreSQL:ää määritettäessä.

• Toisinaan havaitsin replikoinnin jumiutumisen PostgreSQL:ssä ForkBomb-testissä (muistin ylivuoto). ForkBombin jälkeen orjat eivät välttämättä muodosta yhteyttä uudelleen uuteen isäntälaitteeseen. Olen nähnyt tämän vain tuchanka3- ja tuchanka4-klustereissa, joissa replikoinnin synkronisuuden vuoksi master roikkui. Ongelma poistui itsestään, pitkän ajan (noin kahden tunnin) jälkeen. Tämän korjaamiseksi tarvitaan lisää tutkimusta. Oireet ovat samankaltaisia ​​kuin edellisessä bugissa, joka johtuu eri syystä, mutta samoilla seurauksilla.

Krogan kuva otettu deviantart kirjoittajan luvalla:

Lähde: will.com