Failover Cluster PostgreSQL + Patroni. Käyttöönottokokemus

Artikkelissa kerron kuinka lähestyimme PostgreSQL-vikasietoisuutta, miksi siitä tuli meille tärkeä ja mitä lopulta tapahtui.

Meillä on erittäin kuormitettu palvelu: 2,5 miljoonaa käyttäjää maailmanlaajuisesti, yli 50 100 aktiivista käyttäjää päivittäin. Palvelimet sijaitsevat Amazonessa yhdellä Irlannin alueella: yli 50 erilaista palvelinta on jatkuvasti toiminnassa, joista lähes XNUMX on tietokantoja.

Koko tausta on suuri monoliittinen tilallinen Java-sovellus, joka ylläpitää jatkuvaa verkkokantayhteyttä asiakkaan kanssa. Kun useat käyttäjät työskentelevät samalla levyllä samaan aikaan, he kaikki näkevät muutokset reaaliajassa, koska kirjoitamme jokaisen muutoksen tietokantaan. Meillä on noin 10 80 pyyntöä sekunnissa tietokantoihimme. Huippukuormalla Redisissä kirjoitamme 100-XNUMX XNUMX pyyntöä sekunnissa.

Miksi vaihdoimme Rediksestä PostgreSQL:ään

Aluksi palvelumme toimi Redis-avainarvovaraston kanssa, joka tallentaa kaikki tiedot palvelimen RAM-muistiin.

Rediksen plussat:

1. Suuri vastenopeus, koska kaikki on tallennettu muistiin;
2. Varmuuskopioinnin ja replikoinnin helppous.

Rediksen miinukset meille:

1. Varsinaisia ​​liiketoimia ei ole. Yritimme simuloida niitä sovelluksemme tasolla. Valitettavasti tämä ei aina toiminut hyvin ja vaati erittäin monimutkaisen koodin kirjoittamista.
2. Tietojen määrää rajoittaa muistin määrä. Tietomäärän kasvaessa muisti kasvaa, ja lopulta törmäämme valitun ilmentymän ominaisuuksiin, mikä AWS:ssä edellyttää palvelumme pysäyttämistä ilmentymän tyypin vaihtamiseksi.
3. On välttämätöntä ylläpitää jatkuvasti matalaa latenssitasoa, koska. meillä on erittäin suuri määrä pyyntöjä. Optimaalinen viivetaso meille on 17-20 ms. 30-40 ms:n tasolla saamme pitkiä vastauksia sovelluksemme pyyntöihin ja palvelun huononemiseen. Valitettavasti tämä tapahtui meille syyskuussa 2018, jolloin yksi Rediksen tapauksista sai jostain syystä latenssia 2 kertaa tavallista enemmän. Ongelman ratkaisemiseksi pysäytimme palvelun puolivälissä suunnittelemattoman huollon vuoksi ja korvasimme ongelmallisen Redis-esiintymän.
4. Tietojen epäjohdonmukaisuuksien saaminen on helppoa myös pienillä koodivirheillä ja kuluttaa sitten paljon aikaa koodin kirjoittamiseen näiden tietojen korjaamiseksi.

Otimme huomioon haitat ja ymmärsimme, että meidän oli siirryttävä johonkin kätevämpään, jossa on normaalit tapahtumat ja vähemmän riippuvuutta latenssista. Teki tutkimusta, analysoi monia vaihtoehtoja ja valitsi PostgreSQL:n.

Olemme siirtyneet uuteen tietokantaan jo 1,5 vuotta ja olemme siirtäneet vain pienen osan tiedoista, joten nyt työskentelemme samanaikaisesti Rediksen ja PostgreSQL:n kanssa. Lisätietoa tiedon siirtämisen ja vaihtamisen vaiheista tietokantojen välillä on kirjoitettu kollegani artikkeli.

Kun aloitimme muuton, sovelluksemme toimi suoraan tietokannan kanssa ja käytti Rediksen ja PostgreSQL:n pääohjelmistoa. PostgreSQL-klusteri koostui isännästä ja replikistä asynkronisella replikaatiolla. Tietokantakaavio näytti tältä:

PgBouncerin käyttöönotto

Liikkuessamme tuote myös kehittyi: PostgreSQL:llä toimivien käyttäjien ja palvelimien määrä kasvoi, ja meiltä alkoi puuttua yhteyksiä. PostgreSQL luo jokaiselle yhteydelle erillisen prosessin ja kuluttaa resursseja. Voit lisätä yhteyksien määrää tiettyyn pisteeseen asti, muuten on mahdollisuus saada epäoptimaalinen tietokannan suorituskyky. Ihanteellinen vaihtoehto tällaisessa tilanteessa olisi valita yhteyshallinta, joka seisoo tukikohdan edessä.

Meillä oli kaksi vaihtoehtoa yhteydenhallintaan: Pgpool ja PgBouncer. Mutta ensimmäinen ei tue tietokannan käsittelytapaa, joten valitsimme PgBouncerin.

Olemme määrittäneet seuraavan toimintamallin: sovelluksemme käyttää yhtä PgBounceria, jonka takana ovat PostgreSQL-masterit ja jokaisen isäntäkoneen takana on yksi replika asynkronisella replikaatiolla.


Samanaikaisesti emme pystyneet tallentamaan koko datamäärää PostgreSQL:iin ja tietokannan kanssa työskentelyn nopeus oli meille tärkeää, joten aloimme sharida PostgreSQL:ää sovellustasolla. Yllä kuvattu kaava on tähän suhteellisen kätevä: kun lisätään uusi PostgreSQL-sirpale, riittää päivittää PgBouncer-kokoonpano ja sovellus voi heti toimia uuden sirpaleen kanssa.

PgBouncer vikasieto

Tämä järjestelmä toimi siihen asti, kun ainoa PgBouncer-instanssi kuoli. Olemme AWS:ssä, jossa kaikki esiintymät toimivat laitteistolla, joka kuolee ajoittain. Tällaisissa tapauksissa ilmentymä yksinkertaisesti siirtyy uuteen laitteistoon ja toimii uudelleen. Tämä tapahtui PgBouncerin kanssa, mutta se ei ollut käytettävissä. Tämän syksyn seurauksena palvelumme oli poissa käytöstä 25 minuuttia. AWS suosittelee käyttämään tällaisiin tilanteisiin käyttäjäpuolen redundanssia, jota maassamme ei tuolloin otettu käyttöön.

Sen jälkeen pohdimme vakavasti PgBouncer- ja PostgreSQL-klusterien vikasietoisuutta, koska samanlainen tilanne voi tapahtua minkä tahansa AWS-tilin esiintymän kanssa.

Rakensimme PgBouncerin vikasietojärjestelmän seuraavasti: kaikki sovelluspalvelimet käyttävät Network Load Balanceria, jonka takana on kaksi PgBounceria. Jokainen PgBouncer tarkastelee kunkin sirpaleen samaa PostgreSQL-masteria. Jos AWS-esiintymän kaatuminen toistuu, kaikki liikenne ohjataan toisen PgBouncerin kautta. AWS tarjoaa Network Load Balancer -virheensiirron.

Tämä malli helpottaa uusien PgBouncer-palvelimien lisäämistä.

Luo PostgreSQL-virheklusteri

Kun ratkaisimme tämän ongelman, harkitsimme eri vaihtoehtoja: itsekirjoitettu vikasieto, repmgr, AWS RDS, Patroni.

Itse kirjoitetut käsikirjoitukset

He voivat valvoa isäntäkoneen työtä ja, jos se epäonnistuu, siirtää replikan isännälle ja päivittää PgBouncer-kokoonpanon.

Tämän lähestymistavan etuna on maksimaalinen yksinkertaisuus, koska kirjoitat skriptit itse ja ymmärrät tarkalleen, kuinka ne toimivat.

Miinukset:

• Isäntä ei ehkä ole kuollut, vaan verkkovika on saattanut tapahtua. Failover, joka ei ole tietoinen tästä, siirtää replikan isännälle, kun taas vanha mestari jatkaa toimintaansa. Tämän seurauksena saamme kaksi palvelinta isäntäroolissa, emmekä tiedä, kummalla niistä on viimeisimmät ajantasaiset tiedot. Tätä tilannetta kutsutaan myös split-brainiksi;
• Jäimme ilman vastausta. Konfiguraatiossamme isäntä ja yksi replika, vaihdon jälkeen replika siirtyy pääkoneeseen, eikä meillä ole enää replikoita, joten meidän on lisättävä uusi replika manuaalisesti.
• Tarvitsemme lisäseurantaa vikasietotoiminnalle, kun taas meillä on 12 PostgreSQL-sirpaletta, mikä tarkoittaa, että meidän on valvottava 12 klusteria. Sirpaleiden määrän kasvaessa sinun on myös muistettava päivittää vikasieto.

Itsekirjoitettu vikasietoisuus näyttää erittäin monimutkaiselta ja vaatii ei-triviaalia tukea. Yhdellä PostgreSQL-klusterilla tämä olisi helpoin vaihtoehto, mutta se ei skaalaudu, joten se ei sovellu meille.

Repmgr

PostgreSQL-klustereiden replikointihallinta, joka voi hallita PostgreSQL-klusterin toimintaa. Samaan aikaan siinä ei ole automaattista vikasietoa, joten työtä varten sinun on kirjoitettava oma "kääre" valmiin ratkaisun päälle. Joten kaikki voi osoittautua vielä monimutkaisemmaksi kuin itse kirjoitetuilla skripteillä, joten emme edes yrittäneet Repmgr:iä.

AWS RDS

Tukee kaikkea mitä tarvitsemme, osaa tehdä varmuuskopioita ja ylläpitää yhteyksiä. Siinä on automaattinen vaihto: kun isäntäkone kuolee, replikasta tulee uusi isäntä, ja AWS muuttaa dns-tietueen uudeksi isäntäksi, kun taas kopiot voivat sijaita eri AZ:issa.

Haittoja ovat hienosäätöjen puute. Esimerkkinä hienosäädöstä: esiintymillämme on rajoituksia tcp-yhteyksille, joita ei valitettavasti voi tehdä RDS:ssä:

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

Lisäksi AWS RDS on lähes kaksi kertaa kalliimpi kuin tavallinen instanssihinta, mikä oli suurin syy tästä ratkaisusta luopumiseen.

Patroni

Tämä on python-malli PostgreSQL:n hallintaan, jossa on hyvä dokumentaatio, automaattinen vikasieto ja lähdekoodi githubissa.

Patronin plussat:

• Jokainen konfiguraatioparametri on kuvattu, on selvää, kuinka se toimii;
• Automaattinen vikasieto toimii heti alusta alkaen;
• Pythonilla kirjoitettu, ja koska me itse kirjoitamme paljon pythonilla, meidän on helpompi käsitellä ongelmia ja ehkä jopa auttaa projektin kehitystä;
• Hallitsee täysin PostgreSQL:ää, mahdollistaa klusterin kaikkien solmujen kokoonpanon muuttamisen kerralla, ja jos klusteri on käynnistettävä uudelleen uuden määrityksen soveltamiseksi, tämä voidaan tehdä uudelleen Patronilla.

Miinukset:

• Dokumentaatiosta ei käy selväksi, kuinka PgBouncerin kanssa työskennellään oikein. Vaikka sitä on vaikea kutsua miinukseksi, koska Patronin tehtävänä on hallita PostgreSQL:ää, ja miten yhteydet Patroniin sujuu, on jo meidän ongelmamme;
• Esimerkkejä Patronin toteutuksesta suurille volyymeille on vähän, kun taas on monia esimerkkejä toteutuksesta tyhjästä.

Tämän seurauksena valitsimme Patronin luomaan vikasietoklusterin.

Patronin käyttöönottoprosessi

Ennen Patronia meillä oli 12 PostgreSQL-sirua kokoonpanossa, jossa oli yksi isäntä ja yksi replika asynkronisella replikaatiolla. Sovelluspalvelimet pääsivät tietokantoihin Network Load Balancerin kautta, jonka takana oli kaksi PgBouncer-instanssia ja niiden takana olivat kaikki PostgreSQL-palvelimet.


Patronin käyttöönottoa varten meidän piti valita hajautetun tallennusklusterin kokoonpano. Patroni toimii hajautettujen asetusten tallennusjärjestelmien kanssa, kuten etcd, Zookeeper, Consul. Meillä on juuri markkinoilla täysimittainen Consul-klusteri, joka toimii yhdessä Holvin kanssa emmekä käytä sitä enää. Loistava syy aloittaa Consulin käyttö aiottuun tarkoitukseen.

Kuinka Patroni työskentelee konsulin kanssa

Meillä on Consul-klusteri, joka koostuu kolmesta solmusta, ja Patroni-klusteri, joka koostuu johtajasta ja kopiosta (Patroissa isäntä on nimeltään klusterin johtaja ja orjia kutsutaan jäljennöksiksi). Jokainen Patroni-klusterin esiintymä lähettää jatkuvasti tietoa klusterin tilasta Consulille. Siksi Consulilta voit aina selvittää Patroni-klusterin nykyisen kokoonpanon ja kuka on johtaja tällä hetkellä.

Patronin yhdistämiseksi Consuliin riittää, että tutkit virallista dokumentaatiota, jossa sanotaan, että sinun on määritettävä isäntä http- tai https-muodossa riippuen siitä, kuinka työskentelemme Consulin kanssa, ja yhteyskaavio valinnaisesti:

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

Se näyttää yksinkertaiselta, mutta tästä alkavat sudenkuopat. Consulin kanssa työskentelemme suojatun yhteyden kautta https:n kautta ja yhteyskokoonpanomme näyttää tältä:

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

Mutta se ei toimi. Käynnistettäessä Patroni ei voi muodostaa yhteyttä Consuliin, koska se yrittää joka tapauksessa käydä http:n kautta.

Patronin lähdekoodi auttoi ratkaisemaan ongelman. Hyvä, että se on kirjoitettu pythonilla. Osoittautuu, että isäntäparametria ei jäsennetä millään tavalla, ja protokolla on määritettävä kaaviossa. Tältä Consul-työskentelyn konfigurointilohko näyttää meille:

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

konsuli-malli

Joten olemme valinneet kokoonpanolle tallennustilan. Nyt meidän on ymmärrettävä, kuinka PgBouncer muuttaa kokoonpanoaan vaihtaessaan johtajaa Patroni-klusterissa. Asiakirjoissa ei ole vastausta tähän kysymykseen, koska. siellä periaatteessa työtä PgBouncerin kanssa ei kuvata.

Ratkaisua etsiessämme löysimme artikkelin (en valitettavasti muista otsikkoa), jossa kirjoitettiin, että Сonsul-malli auttoi paljon PgBouncerin ja Patronin yhdistämisessä. Tämä sai meidät tutkimaan, miten Consul-malli toimii.

Kävi ilmi, että Consul-template valvoo jatkuvasti Consulin PostgreSQL-klusterin konfiguraatiota. Kun johtaja vaihtuu, se päivittää PgBouncerin kokoonpanon ja lähettää komennon ladata se uudelleen.

Mallin iso plussa on se, että se tallennetaan koodina, joten uutta sirpaletta lisättäessä riittää, että tehdään uusi commit ja päivitetään malli automaattisesti tukemalla Infrastruktuuri koodina -periaatetta.

Uusi arkkitehtuuri Patronin kanssa

Tuloksena saimme seuraavan työsuunnitelman:


Kaikki sovelluspalvelimet käyttävät Balanceria → sen takana on kaksi PgBouncer-instanssia → jokaisessa ilmentymässä käynnistetään Consul-malli, joka tarkkailee kunkin Patroni-klusterin tilaa ja seuraa PgBouncer-konfiguraation relevanssia, joka lähettää pyyntöjä nykyiselle johtajalle. jokaisesta klusterista.

Manuaalinen testaus

Suoritimme tämän järjestelmän ennen sen käynnistämistä pienessä testiympäristössä ja tarkistimme automaattisen vaihdon toiminnan. He avasivat laudan, siirsivät tarraa ja sillä hetkellä he "tappasivat" klusterin johtajan. AWS:ssä tämä on yhtä helppoa kuin ilmentymän sulkeminen konsolin kautta.

Tarra palasi takaisin 10-20 sekunnissa ja alkoi sitten taas liikkua normaalisti. Tämä tarkoittaa, että Patroni-klusteri toimi oikein: se vaihtoi johtajaa, lähetti tiedot Consulille, ja Consul-template poimi nämä tiedot välittömästi, korvasi PgBouncer-kokoonpanon ja lähetti käskyn ladata uudelleen.

Kuinka selviytyä suuresta kuormituksesta ja pitää seisokit mahdollisimman vähäisinä?

Kaikki toimii täydellisesti! Mutta on uusia kysymyksiä: Miten se toimii suurella kuormituksella? Kuinka nopeasti ja turvallisesti viedä kaikki tuotantoon?

Testiympäristö, jossa suoritamme kuormitustestauksen, auttaa meitä vastaamaan ensimmäiseen kysymykseen. Se on arkkitehtuuriltaan täysin identtinen tuotannon kanssa ja on tuottanut testidataa, joka vastaa suunnilleen tuotantomäärää. Päätämme vain "tappaa" yhden PostgreSQL-mastereista testin aikana ja katsoa mitä tapahtuu. Mutta sitä ennen on tärkeää tarkistaa automaattinen rullaus, koska tässä ympäristössä meillä on useita PostgreSQL-sirpaleita, joten saamme erinomaiset konfigurointiskriptien testaukset ennen tuotantoa.

Molemmat tehtävät näyttävät kunnianhimoisilta, mutta meillä on PostgreSQL 9.6. Voimmeko päivittää heti versioon 11.2?

Päätämme tehdä sen kahdessa vaiheessa: päivitä ensin versioon 2 ja käynnistä sitten Patroni.

PostgreSQL-päivitys

Voit päivittää PostgreSQL-version nopeasti käyttämällä vaihtoehtoa -k, jossa kovat linkit luodaan levylle eikä tietojasi tarvitse kopioida. 300-400 Gt:n pohjalta päivitys kestää 1 sekunnin.

Meillä on paljon sirpaleita, joten päivitys on tehtävä automaattisesti. Tätä varten kirjoitimme Ansible-ohjekirjan, joka hoitaa koko päivitysprosessin puolestamme:

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

Tässä on tärkeää huomata, että ennen päivityksen aloittamista sinun on suoritettava se parametrilla --tarkistaavarmistaaksesi, että voit päivittää. Skriptimme myös korvaa asetukset päivityksen ajaksi. Käsikirjoituksemme valmistui 30 sekunnissa, mikä on erinomainen tulos.

Käynnistä Patroni

Voit ratkaista toisen ongelman katsomalla Patroni-kokoonpanoa. Virallisessa arkistossa on esimerkkikonfiguraatio initdb:llä, joka vastaa uuden tietokannan alustamisesta, kun käynnistät Patronin ensimmäisen kerran. Mutta koska meillä on jo valmis tietokanta, poistimme tämän osan kokoonpanosta.

Kun aloimme asentaa Patronia jo olemassa olevaan PostgreSQL-klusteriin ja käyttää sitä, törmäsimme uuteen ongelmaan: molemmat palvelimet aloittivat johtajana. Patroni ei tiedä mitään klusterin varhaisesta tilasta ja yrittää käynnistää molemmat palvelimet kahtena erillisenä klusterina, joilla on sama nimi. Tämän ongelman ratkaisemiseksi sinun on poistettava hakemisto, joka sisältää tietoja orjasta:

rm -rf /var/lib/postgresql/

Tämä on tehtävä vain orjalle!

Kun puhdas replika on liitetty, Patroni tekee perusvarmuuskopion johtajan ja palauttaa sen replikaan ja ottaa sitten kiinni nykyisen tilan wallokien mukaan.

Toinen kohtaamamme vaikeus on se, että kaikki PostgreSQL-klusterit on oletuksena nimetty main. Kun kumpikin klusteri ei tiedä toisesta mitään, tämä on normaalia. Mutta kun haluat käyttää Patronia, kaikilla klustereilla on oltava yksilöllinen nimi. Ratkaisu on muuttaa klusterin nimi PostgreSQL-kokoonpanossa.

kuormitustesti

Olemme käynnistäneet testin, joka simuloi käyttökokemusta laudoilla. Kun kuormitus saavutti keskimääräisen päivittäisen arvomme, toistimme täsmälleen saman testin, sammutimme yhden esiintymän PostgreSQL-johtajalla. Automaattinen vikasieto toimi odotetusti: Patroni vaihtoi johtajaa, Consul-template päivitti PgBouncerin kokoonpanon ja lähetti käskyn ladata uudelleen. Grafanan kaavioidemme mukaan oli selvää, että tietokantayhteyteen liittyy 20-30 sekunnin viiveitä ja pieni määrä virheitä palvelimilta. Tämä on normaali tilanne, tällaiset arvot ovat hyväksyttäviä vikasietotilassamme ja ovat ehdottomasti parempia kuin palvelun seisokkiaika.

Tuo Patroni tuotantoon

Tuloksena päädyimme seuraavanlaiseen suunnitelmaan:

• Ota käyttöön Consul-malli PgBouncer-palvelimille ja käynnistä se;
• PostgreSQL-päivitykset versioon 11.2;
• Muuta klusterin nimeä;
• Patroni-klusterin käynnistäminen.

Samaan aikaan järjestelmämme antaa meille mahdollisuuden tehdä ensimmäinen piste melkein milloin tahansa, voimme poistaa jokaisen PgBouncerin vuorollaan työstä ja ottaa käyttöön ja käyttää konsulimallia siinä. Niin teimme.

Nopeaa käyttöönottoa varten käytimme Ansiblea, koska olemme jo testanneet kaikki pelikirjat testiympäristössä ja koko skriptin suoritusaika oli 1,5–2 minuuttia jokaiselle sirpaleelle. Voisimme levittää kaiken vuorollaan jokaiselle sirpaleelle pysäyttämättä palveluamme, mutta meidän on sammutettava jokainen PostgreSQL useiksi minuuteiksi. Tässä tapauksessa käyttäjät, joiden tiedot ovat tällä sirpaleella, eivät voi toimia täysin tällä hetkellä, emmekä hyväksy tätä.

Pääsy tästä tilanteesta oli suunniteltu huolto, joka tehdään 3 kuukauden välein. Tämä on ajoitetun työn ikkuna, jolloin suljemme palvelumme kokonaan ja päivitämme tietokanta-instanssimme. Seuraavaan ikkunaan oli jäljellä viikko, ja päätimme vain odottaa ja valmistautua eteenpäin. Odotusajan aikana turvasimme itsemme lisäksi: jokaiselle PostgreSQL-sirpaleelle esitimme ylimääräisen replikan siltä varalta, että uusimpien tietojen säilyttäminen epäonnistuisi, ja lisäsimme jokaiselle sirpaleelle uuden esiintymän, josta pitäisi tulla uusi kopio Patroni-klusterissa, jotta ei suoritettaisi komentoa tietojen poistamiseksi. Kaikki tämä auttoi minimoimaan virheriskin.


Käynnistimme palvelumme uudelleen, kaikki toimi niin kuin pitää, käyttäjät jatkoivat työtä, mutta kaavioissa havaitsimme Consul-palvelimien epänormaalin suuren kuormituksen.


Miksi emme nähneet tätä testiympäristössä? Tämä ongelma havainnollistaa hyvin, että on tarpeen noudattaa Infrastruktuuri koodina -periaatetta ja jalostaa koko infrastruktuuria testiympäristöistä tuotantoon. Muuten saamme ongelman helposti. Mitä tapahtui? Consul ilmestyi ensin tuotantoon ja sitten testiympäristöihin, minkä seurauksena testiympäristöissä Consulin versio oli korkeampi kuin tuotannossa. Juuri yhdessä julkaisussa prosessorivuoto korjattiin työskennellessäsi consul-templaten kanssa. Siksi yksinkertaisesti päivitimme Consulin, mikä ratkaisi ongelman.

Käynnistä Patroni-klusteri uudelleen

Saimme kuitenkin uuden ongelman, jota emme edes aavistaneet. Kun päivität Consulin, poistamme Consul-solmun klusterista komennolla consul jätä → Patroni muodostaa yhteyden toiseen Consul-palvelimeen → kaikki toimii. Mutta kun saavutimme Consul-klusterin viimeisen esiintymän ja lähetimme siihen konsulipoistumiskomennon, kaikki Patroni-klusterit yksinkertaisesti käynnistyivät uudelleen, ja lokeissa näimme seuraavan virheen:

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

Patroni-klusteri ei pystynyt hakemaan tietoja klusteristaan ​​ja käynnistettiin uudelleen.

Ratkaisun löytämiseksi otimme yhteyttä Patronin kirjoittajiin githubin ongelman kautta. He ehdottivat parannuksia määritystiedostoihimme:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

Pystyimme toistamaan ongelman testiympäristössä ja testasimme näitä vaihtoehtoja siellä, mutta valitettavasti ne eivät toimineet.

Ongelma on edelleen ratkaisematta. Aiomme kokeilla seuraavia ratkaisuja:

• Käytä Consul-agenttia jokaisessa Patroni-klusteriinstanssissa;
• Korjaa ongelma koodissa.

Ymmärrämme, missä virhe tapahtui: ongelma on luultavasti oletusaikakatkaisun käyttö, jota ei ohiteta asetustiedoston kautta. Kun viimeinen Consul-palvelin poistetaan klusterista, koko Consul-klusteri jumiutuu yli sekunnin, minkä vuoksi Patroni ei saa klusterin tilaa ja käynnistää koko klusterin kokonaan uudelleen.

Onneksi emme havainneet enempää virheitä.

Patronin käytön tulokset

Patronin onnistuneen julkaisun jälkeen lisäsimme jokaiseen klusteriin yhden replikan. Nyt jokaisessa klusterissa on näennäinen päätösvaltaisuus: yksi johtaja ja kaksi jäljennöstä turvaverkkoa varten, jos aivot jakautuvat vaihdon yhteydessä.


Patroni on työskennellyt tuotannon parissa yli kolme kuukautta. Tänä aikana hän on jo onnistunut auttamaan meitä. Äskettäin yhden klusterin johtaja kuoli AWS:ssä, automaattinen vikasieto toimi ja käyttäjät jatkoivat työtä. Patroni suoritti päätehtävänsä.

Pieni yhteenveto Patronin käytöstä:

• Konfiguraatiomuutosten helppous. Riittää, kun muutat kokoonpanoa yhdessä esiintymässä ja se vedetään koko klusteriin. Jos uuden kokoonpanon käyttöönotto edellyttää uudelleenkäynnistystä, Patroni ilmoittaa siitä. Patroni voi käynnistää koko klusterin uudelleen yhdellä komennolla, mikä on myös erittäin kätevää.
• Automaattinen vikasieto toimii ja on jo onnistunut auttamaan meitä.
• PostgreSQL-päivitys ilman sovelluksen seisokkeja. Sinun on ensin päivitettävä kopiot uuteen versioon, sitten vaihdettava Patroni-klusterin johtaja ja päivitettävä vanha johtaja. Tässä tapauksessa tarvittava automaattisen vikasietoisuuden testaus tapahtuu.

Lähde: will.com