Patronin päätavoite on tarjota korkeaa käytettävyyttä PostgreSQL:lle. Mutta Patroni on vain malli, ei valmis työkalu (joka yleensä sanotaan dokumentaatiossa). Ensi silmäyksellä, kun olet asettanut Patronin testilaboratorioon, näet, kuinka loistava työkalu se on ja kuinka helposti se käsittelee yrityksiämme murtaa klusteri. Käytännössä tuotantoympäristössä kaikki ei kuitenkaan aina tapahdu niin kauniisti ja tyylikkäästi kuin testilaboratoriossa.
Kerron vähän itsestäni. Aloitin järjestelmänvalvojana. Työskenteli verkkokehityksen parissa. Olen työskennellyt Data Egretissä vuodesta 2014. Yhtiö harjoittaa konsultointia Postgres-alalla. Ja palvelemme täsmälleen Postgresia ja työskentelemme Postgresin kanssa päivittäin, joten meillä on toimintaan liittyvä erilainen asiantuntemus.
Ja vuoden 2018 lopulla aloimme hitaasti käyttää Patronia. Ja kokemusta on kertynyt jonkin verran. Jotenkin diagnosoimme sen, viritimme sitä ja päädyimme parhaisiin käytäntöihimme. Ja tässä raportissa puhun niistä.
Postgresin lisäksi rakastan Linuxia. Tykkään puuhailla siinä ja tutkia, tykkään kerätä ytimiä. Rakastan virtualisointia, säiliöitä, telakointiasemaa, Kubernetesia. Kaikki tämä kiinnostaa minua, koska vanhat järjestelmänvalvojan tavat vaikuttavat. Pidän seurannasta. Ja rakastan postgres-asioita, jotka liittyvät hallintaan, eli replikointiin, varmuuskopiointiin. Ja vapaa-ajallani kirjoitan Go-kirjaan. En ole ohjelmistosuunnittelija, kirjoitan vain itselleni Gossa. Ja se tuottaa minulle iloa.
- Luulen, että monet teistä tietävät, että Postgresilla ei ole HA:ta (High Availability) valmiina. Saadaksesi HA:n, sinun on asennettava jotain, konfiguroitava se, ponnisteltava ja hankittava se.
- Työkaluja on useita ja Patroni on yksi niistä, joka ratkaisee HA:n melko siististi ja erittäin hyvin. Mutta laittamalla se kaikki testilaboratorioon ja suorittamalla sitä, voimme nähdä, että kaikki toimii, voimme toistaa joitain ongelmia, nähdä kuinka Patroni palvelee niitä. Ja näemme, että kaikki toimii loistavasti.
- Mutta käytännössä kohtasimme erilaisia ongelmia. Ja aion puhua näistä ongelmista.
- Kerron sinulle kuinka diagnosoimme sen, mitä säätimme - auttoiko se meitä vai ei.
- En kerro sinulle kuinka Patroni asennetaan, koska voit googlettaa Internetissä, voit katsoa asetustiedostoja ymmärtääksesi kuinka kaikki alkaa, kuinka se on määritetty. Ymmärrät kaavioita, arkkitehtuuria, löydät tietoa siitä Internetistä.
- En puhu kenenkään muun kokemuksista. Puhun vain kohtaamistamme ongelmista.
- Enkä puhu Patronin ja PostgreSQL:n ulkopuolella olevista ongelmista. Jos esimerkiksi tasapainottamiseen liittyy ongelmia, kun klusterimme on romahtanut, en puhu siitä.
Ja pieni vastuuvapauslauseke ennen kuin aloitamme raporttimme.
Kaikki nämä ongelmat, joita kohtasimme, meillä oli ensimmäisten 6-7-8 kuukauden aikana. Ajan myötä pääsimme sisäisiin parhaisiin käytäntöihimme. Ja ongelmamme katosivat. Siksi raportti julkistettiin noin kuusi kuukautta sitten, kun se kaikki oli tuoreessa päässäni ja muistin sen kaiken täydellisesti.
Raportin valmistelun aikana nostin jo vanhoja postmortemeja, katselin lokeja. Ja jotkin yksityiskohdat saattavat unohtua tai joitain yksityiskohtia ei ole voitu täysin tutkia ongelmien analysoinnin aikana, joten joissain kohdissa saattaa vaikuttaa siltä, että ongelmia ei ole täysin mietitty tai tiedosta puuttuu. Ja siksi pyydän teitä antamaan minulle anteeksi tämän hetken.
Mikä on Patroni?
- Tämä on malli HA:n rakentamiseen. Näin asiakirjoissa lukee. Ja minun näkökulmastani tämä on erittäin oikea selvennys. Patroni ei ole hopealuoti, joka ratkaisee kaikki ongelmasi, eli sinun on ponnisteltava saadaksesi sen toimimaan ja tuomaan etuja.
- Tämä on agenttipalvelu, joka asennetaan jokaiseen tietokantapalveluun ja on eräänlainen aloitusjärjestelmä Postgresille. Se käynnistää Postgresin, pysäyttää, käynnistää uudelleen, konfiguroi uudelleen ja muuttaa klusterin topologiaa.
- Vastaavasti klusterin tilan, sen nykyisen esityksen tallentamiseksi, miltä näyttää, tarvitaan jonkinlaista tallennustilaa. Ja tästä näkökulmasta Patroni valitsi tilan tallentamisen ulkoiseen järjestelmään. Se on hajautettu asetusten tallennusjärjestelmä. Se voi olla Etcd, Consul, ZooKeeper tai kubernetes Etcd, eli yksi näistä vaihtoehdoista.
- Ja yksi Patronin ominaisuuksista on, että saat automaattisen tiedoston pois laatikosta vain määrittämällä sen. Jos otamme vertailuksi Repmgr:n, niin tiedosto sisältyy siihen. Repmgr:n avulla saamme vaihdon, mutta jos haluamme automaattisen tiedoston, meidän on määritettävä se lisäksi. Patronilla on jo automaattinen suodatin.
- Ja on monia muita asioita. Esimerkiksi kokoonpanojen ylläpito, uusien replikoiden kaataminen, varmuuskopiointi jne. Mutta tämä ei kuulu raportin piiriin, en puhu siitä.
Ja pieni tulos on, että Patronin päätehtävänä on tehdä autotiedosto hyvin ja luotettavasti niin, että klusterimme pysyy toimintakunnossa eikä sovellus huomaa muutoksia klusterin topologiassa.
Mutta kun aloitamme Patronin käytön, järjestelmästämme tulee hieman monimutkaisempi. Jos aiemmin meillä oli Postgres, niin Patronia käytettäessä saamme itse Patronin, saamme DCS:n, johon tila on tallennettu. Ja kaiken pitää jotenkin toimia. Joten mikä voi mennä pieleen?
Voi tauko:
- Postgres saattaa katketa. Se voi olla master tai kopio, yksi niistä voi epäonnistua.
- Patroni itse saattaa rikkoutua.
- DCS, johon tila on tallennettu, voi rikkoutua.
- Ja verkko voi katketa.
Kaikkia näitä asioita käsittelen mietinnössä.
Tarkastelen tapauksia sitä mukaa, kun niistä tulee monimutkaisempia, en siitä näkökulmasta, että tapaukseen sisältyy monia osia. Ja subjektiivisten tunteiden näkökulmasta, että tämä kotelo oli minulle vaikea, sitä oli vaikea purkaa ... ja päinvastoin, osa kotelosta oli kevyt ja se oli helppo purkaa.
Ja ensimmäinen tapaus on helpoin. Tämä on tilanne, kun otimme tietokantaklusterin ja otimme käyttöön DCS-tallennustilan samassa klusterissa. Tämä on yleisin virhe. Tämä on arkkitehtuurien rakentamisen virhe, eli eri komponenttien yhdistäminen samaan paikkaan.
Joten, oli arkistointi, mennään käsittelemään mitä tapahtui.
Ja tässä olemme kiinnostuneita siitä, milloin tiedosto tapahtui. Toisin sanoen olemme kiinnostuneita tästä hetkestä, jolloin klusterin tila muuttui.
Mutta arkistointi ei aina ole välitön, eli se ei vie mitään aikayksikköä, se voi viivästyä. Se voi olla pitkäkestoinen.
Siksi sillä on alkamisaika ja lopetusaika, eli se on jatkuva tapahtuma. Ja jaamme kaikki tapahtumat kolmeen aikaväliin: meillä on aikaa ennen tiedostoa, arkistoinnin aikana ja arkistoinnin jälkeen. Toisin sanoen otamme huomioon kaikki tapahtumat tällä aikajanalla.
Ja ensimmäinen asia, kun arkistointi tapahtui, etsimme tapahtuneen syytä, mikä oli syy siihen, mikä johti arkistointiin.
Jos katsomme tukia, ne ovat klassisia Patroni-tukeja. Hän kertoo meille niissä, että palvelimesta on tullut isäntä ja isäntäaseman rooli on siirtynyt tälle solmulle. Tässä se on korostettu.
Seuraavaksi meidän on ymmärrettävä, miksi arkistointi tapahtui, eli mitä tapahtumia tapahtui, jotka saivat pääroolin siirtymään solmusta toiseen. Ja tässä tapauksessa kaikki on yksinkertaista. Meillä on virhe vuorovaikutuksessa tallennusjärjestelmän kanssa. Mestari tajusi, että hän ei voinut työskennellä DCS: n kanssa, eli vuorovaikutuksessa oli jonkinlainen ongelma. Ja hän sanoo, ettei voi enää olla mestari ja eroaa. Tämä rivi "alennettu itse" sanoo juuri sen.
Jos tarkastelemme arkistointia edeltäneitä tapahtumia, voimme nähdä siellä juuri ne syyt, jotka olivat ongelmana ohjatun toiminnon jatkamiselle.
Jos katsomme Patroni-lokeja, näemme, että meillä on paljon virheitä, aikakatkaisuja, eli Patroni-agentti ei voi toimia DCS:n kanssa. Tässä tapauksessa tämä on konsuliagentti, joka kommunikoi portissa 8500.
Ja ongelma tässä on, että Patroni ja tietokanta toimivat samalla isännällä. Ja Consul-palvelimet käynnistettiin samassa solmussa. Luomalla kuormituksen palvelimelle loimme ongelmia myös Consul-palvelimille. He eivät pystyneet kommunikoimaan kunnolla.
Jonkin ajan kuluttua, kun taakka laantui, Patronimme pystyi jälleen kommunikoimaan agenttien kanssa. Normaali työ jatkui. Ja samasta Pgdb-2-palvelimesta tuli taas isäntä. Eli tapahtui pieni kääntö, jonka vuoksi solmu erosi päällikön valtuudesta ja otti ne sitten uudelleen haltuunsa, eli kaikki palasi entisellään.
Ja tätä voidaan pitää vääränä hälytyksenä tai voidaan pitää Patronin tehneen kaiken oikein. Toisin sanoen hän tajusi, että hän ei voinut ylläpitää klusterin tilaa, ja poisti valtuutensa.
Ja tässä ongelma johtui siitä, että Consul-palvelimet ovat samalla laitteistolla kuin tukikohdat. Näin ollen mikä tahansa kuormitus: olipa kyseessä levyjen tai prosessorien kuormitus, se vaikuttaa myös vuorovaikutukseen Consul-klusterin kanssa.
Ja päätimme, että sen ei pitäisi asua yhdessä, jaoimme erillisen klusterin konsulille. Ja Patroni työskenteli jo erillisen konsulin kanssa, eli siellä oli erillinen Postgres-klusteri, erillinen konsuliklusteri. Tämä on perusohje näiden kaikkien tavaroiden kantamiseen ja säilyttämiseen, jotta ne eivät asu yhdessä.
Vaihtoehtoisesti voit kiertää parametreja ttl, loop_wait, retry_timeout, eli yrittää selviytyä näistä lyhytaikaisista kuormitushuippuista lisäämällä näitä parametreja. Mutta tämä ei ole sopivin vaihtoehto, koska tämä kuorma voi olla pitkä. Ja me yksinkertaisesti ylitämme näiden parametrien rajat. Ja se ei ehkä todellakaan auta.
Ensimmäinen ongelma, kuten ymmärrät, on yksinkertainen. Otimme ja laitoimme DCS:n yhteen alustan kanssa, meillä oli ongelma.
Toinen ongelma on samanlainen kuin ensimmäinen. Se on samanlainen siinä mielessä, että meillä on jälleen yhteentoimivuusongelmia DCS-järjestelmän kanssa.
Jos katsomme lokeja, näemme, että meillä on jälleen viestintävirhe. Ja Patroni sanoo, etten voi olla vuorovaikutuksessa DCS:n kanssa, joten nykyinen isäntälaite siirtyy replikatilaan.
Vanhasta mestarista tulee kopio, täällä Patroni toimii niin kuin pitääkin. Se suorittaa pg_rewind kelatakseen tapahtumalokin taaksepäin ja muodostaa sitten yhteyden uuteen isäntälaitteeseen saadakseen kiinni uuteen päälaitteeseen. Täällä Patroni harjoittelee, kuten pitää.
Tästä meidän on löydettävä tiedostoa edeltänyt paikka, eli ne virheet, jotka aiheuttivat arkistoinnin. Ja tässä suhteessa Patroni-lokit ovat melko käteviä käsitellä. Hän kirjoittaa samoja viestejä tietyin väliajoin. Ja jos alamme selata näitä lokeja nopeasti, niin näemme lokeista, että lokit ovat muuttuneet, mikä tarkoittaa, että joitain ongelmia on alkanut. Palaamme nopeasti tähän paikkaan, katsotaan mitä tapahtuu.
Ja normaalitilanteessa lokit näyttävät suunnilleen tältä. Lukon omistaja tarkistetaan. Ja jos esimerkiksi omistaja on vaihtunut, voi tapahtua joitain tapahtumia, joihin Patronin on reagoitava. Mutta tässä tapauksessa olemme kunnossa. Etsimme paikkaa, josta virheet alkoivat.
Ja vieritettyämme kohtaan, jossa virheet alkoivat ilmaantua, näemme, että meillä on ollut automaattinen tiedostonvaihto. Ja koska virheemme liittyivät vuorovaikutukseen DCS:n kanssa ja meidän tapauksessamme käytimme Consulia, katsomme myös Consul-lokeja, mitä siellä tapahtui.
Karkeasti vertaamalla arkistointiaikaa ja konsulilokien aikaa, huomaamme, että naapurimme konsuliklusterissa alkoivat epäillä muiden konsuliklusterin jäsenten olemassaoloa.
Ja jos katsot myös muiden konsuliagenttien lokeja, voit myös nähdä, että siellä on meneillään jonkinlainen verkon romahdus. Ja kaikki konsuliklusterin jäsenet epäilevät toistensa olemassaoloa. Ja tämä oli sysäyksen tekijälle.
Jos katsot mitä tapahtui ennen näitä virheitä, näet, että siellä on kaikenlaisia virheitä, esimerkiksi määräaika, RPC putosi, eli konsuliklusterin jäsenten keskinäisessä vuorovaikutuksessa on selvästi jonkinlainen ongelma. .
Yksinkertaisin vastaus on korjata verkko. Mutta minulle, palkintokorokkeella seisovana, tämä on helppo sanoa. Mutta olosuhteet ovat sellaiset, ettei asiakkaalla ole aina varaa korjata verkkoa. Hän saattaa asua DC-verkossa eikä välttämättä pysty korjaamaan verkkoa, vaikuttaa laitteisiin. Ja siksi tarvitaan muita vaihtoehtoja.
Vaihtoehtoja on:
- Yksinkertaisin vaihtoehto, joka on mielestäni kirjoitettu jopa dokumentaatioon, on poistaa konsulin tarkistukset käytöstä, eli yksinkertaisesti ohittaa tyhjä taulukko. Ja kerromme konsuliagentille, ettei hän käytä shekkejä. Näillä tarkistuksilla voimme jättää nämä verkkomyrskyt huomiotta emmekä käynnistä tiedostoa.
- Toinen vaihtoehto on tarkistaa raft_multiplier. Tämä on itse Consul-palvelimen parametri. Oletusarvona se on 5. Tätä arvoa suositellaan vaiheistusympäristöjen dokumentaatiossa. Itse asiassa tämä vaikuttaa Consul-verkoston jäsenten välisten viestien tiheyteen. Itse asiassa tämä parametri vaikuttaa palveluviestinnän nopeuteen Consul-klusterin jäsenten välillä. Ja tuotannossa on jo suositeltavaa pienentää sitä, jotta solmut vaihtavat viestejä useammin.
- Toinen vaihtoehto, jonka olemme keksineet, on lisätä Consul-prosessien prioriteettia muiden prosessien joukossa käyttöjärjestelmän prosessin ajastimelle. On olemassa sellainen "mukava" parametri, se vain määrittää prosessien prioriteetin, jonka käyttöjärjestelmän ajastin ottaa huomioon ajoittaessaan. Olemme myös alentaneet konsuliagenttien mukavaa arvoa, ts. lisäsi prioriteettia, jotta käyttöjärjestelmä antaa Consul-prosesseille enemmän aikaa työskennellä ja suorittaa koodinsa. Meidän tapauksessamme tämä ratkaisi ongelmamme.
- Toinen vaihtoehto on olla käyttämättä konsulia. Minulla on ystävä, joka on Etcd:n suuri kannattaja. Ja riitelemme hänen kanssaan säännöllisesti kumpi on parempi jne. vai konsuli. Mutta kumpi on parempi, olemme yleensä hänen kanssaan samaa mieltä siitä, että Consulilla on agentti, jonka pitäisi toimia jokaisessa tietokannan solmussa. Toisin sanoen Patronin vuorovaikutus konsuliklusterin kanssa kulkee tämän agentin kautta. Ja tästä agentista tulee pullonkaula. Jos agentille tapahtuu jotain, Patroni ei voi enää työskennellä Consul-klusterin kanssa. Ja tämä on ongelma. Etcd-suunnitelmassa ei ole agenttia. Patroni voi työskennellä suoraan Etcd-palvelimien luettelon kanssa ja olla jo yhteydessä niiden kanssa. Tässä suhteessa, jos käytät Etcd:tä yrityksessäsi, niin Etcd on todennäköisesti parempi valinta kuin Consul. Mutta meitä asiakkaitamme rajoittaa aina se, mitä asiakas on valinnut ja mitä hän käyttää. Ja meillä on konsuli suurimmaksi osaksi kaikille asiakkaille.
- Ja viimeinen kohta on parametrien arvojen tarkistaminen. Voimme nostaa näitä parametreja siinä toivossa, että lyhytaikaiset verkko-ongelmamme ovat lyhyitä eivätkä jää näiden parametrien alueen ulkopuolelle. Tällä tavalla voimme vähentää Patronin aggressiivisuutta automaattiseen tiedostoon, jos verkko-ongelmia ilmenee.
Luulen, että monet Patronia käyttävät tuntevat tämän komennon.
Tämä komento näyttää klusterin nykyisen tilan. Ja ensi silmäyksellä tämä kuva saattaa näyttää normaalilta. Meillä on isäntä, meillä on kopio, replikointiviivettä ei ole. Mutta tämä kuva on normaali täsmälleen, kunnes tiedämme, että tässä klusterissa pitäisi olla kolme solmua, ei kaksi.
Näin ollen siellä oli automaattinen tiedosto. Ja tämän automaattisen tiedoston jälkeen kopiomme katosi. Meidän täytyy selvittää, miksi hän katosi, ja tuoda hänet takaisin, palauttaa hänet. Ja menemme taas lokeihin ja katsomme, miksi meillä oli automaattinen tiedostonvaihto.
Tässä tapauksessa toisesta kopiosta tuli mestari. Täällä on kaikki hyvin.
Ja meidän on tarkasteltava kopiota, joka putosi ja joka ei ole klusterissa. Avaamme Patroni-lokit ja näemme, että meillä oli ongelma muodostaessamme yhteyttä klusteriin pg_rewind-vaiheessa. Jotta voit muodostaa yhteyden klusteriin, sinun on kelattava tapahtumaloki taaksepäin, pyydettävä vaadittu tapahtumaloki isännältä ja sen avulla saatava isäntä kiinni.
Tässä tapauksessa meillä ei ole tapahtumalokia, eikä replika voi käynnistyä. Vastaavasti pysäytämme Postgresin virheellä. Ja siksi se ei ole klusterissa.
Meidän on ymmärrettävä, miksi se ei ole klusterissa ja miksi lokeja ei ollut. Menemme uuden mestarin luo ja katsomme mitä hänellä on lokeissa. Osoittautuu, että kun pg_rewind tehtiin, tapahtui tarkistuspiste. Ja jotkut vanhoista tapahtumalokeista nimettiin yksinkertaisesti uudelleen. Kun vanha isäntä yritti muodostaa yhteyden uuteen isäntään ja kysellä näitä lokeja, ne nimettiin jo uudelleen, niitä ei vain ollut olemassa.
Vertailin aikaleimoja, kun nämä tapahtumat tapahtuivat. Ja siellä ero on kirjaimellisesti 150 millisekuntia, eli tarkistuspiste suoritettiin 369 millisekunnissa, WAL-segmentit nimettiin uudelleen. Ja kirjaimellisesti vuonna 517, 150 millisekunnin jälkeen, vanhan replikan kelaus alkoi. Eli kirjaimellisesti 150 millisekuntia riitti meille, jotta kopio ei voinut muodostaa yhteyttä ja ansaita.
Mitkä ovat vaihtoehdot?
Käytimme alun perin replikointipaikkoja. Ajattelimme, että se oli hyvä. Vaikka toiminnan ensimmäisessä vaiheessa sammutimme paikat. Meistä tuntui, että jos slotit keräävät paljon WAL-segmenttejä, voimme pudottaa masterin. Hän putoaa. Kärsimme jonkin aikaa ilman paikkoja. Ja tajusimme, että tarvitsemme lähtö- ja saapumisaikoja, ja palautimme ne.
Mutta tässä on ongelma, että kun isäntä menee replikaan, se poistaa aikavälit ja poistaa WAL-segmentit paikkojen mukana. Tämän ongelman poistamiseksi päätimme nostaa wal_keep_segments-parametria. Se on oletuksena 8 segmenttiä. Nostimme sen 1 000:een ja katsoimme, kuinka paljon vapaata tilaa meillä oli. Lahjoitimme 16 gigatavua wal_keep_segments-palveluun. Toisin sanoen vaihtaessamme meillä on aina 16 gigatavun varaus tapahtumalokeja kaikissa solmuissa.
Ja plus - se on edelleen tärkeä pitkäaikaisissa huoltotehtävissä. Oletetaan, että meidän on päivitettävä yksi replikoista. Ja haluamme sammuttaa sen. Meidän on päivitettävä ohjelmisto, ehkä käyttöjärjestelmä, jotain muuta. Ja kun sammutamme replikan, myös kyseisen replikan paikka poistetaan. Ja jos käytämme pientä wal_keep_segments-parametria, tapahtumalokit menetetään, jos replikaa ei ole pitkään aikaan. Nostamme replikan, se pyytää niitä tapahtumalokeja, joissa se pysähtyi, mutta ne eivät välttämättä ole pääkoneessa. Ja replika ei myöskään voi muodostaa yhteyttä. Siksi meillä on suuri varasto aikakauslehtiä.
Meillä on tuotantopohja. Projekteja on jo käynnissä.
Siellä oli arkisto. Menimme sisään ja katsoimme - kaikki on kunnossa, kopiot ovat paikoillaan, replikointiviivettä ei ole. Myöskään lokeissa ei ole virheitä, kaikki on kunnossa.
Tuotetiimi sanoo, että dataa pitäisi olla, mutta näemme sen yhdestä lähteestä, mutta emme näe sitä tietokannassa. Ja meidän on ymmärrettävä, mitä heille tapahtui.
On selvää, että pg_rewind missasi ne. Ymmärsimme tämän heti, mutta menimme katsomaan mitä tapahtui.
Lokeista voimme aina löytää, milloin arkistointi tapahtui, kenestä tuli isäntä, ja voimme määrittää, kuka oli vanha isäntä ja milloin hän halusi tulla replikiksi, eli tarvitsemme näitä lokeja selvittääksemme tapahtumalokien määrän. oli hukassa.
Vanha mestarimme on käynnistynyt uudelleen. Ja Patroni rekisteröitiin autorunissa. Patroni lanseerattiin. Sitten hän aloitti Postgresin. Tarkemmin sanottuna ennen Postgresin käynnistämistä ja ennen kuin se teki siitä replikan, Patroni käynnisti pg_rewind-prosessin. Näin ollen hän poisti osan tapahtumalokeista, latasi uusia ja muodosti yhteyden. Täällä Patroni työskenteli älykkäästi, eli odotetusti. Klusteri on palautettu. Meillä oli 3 solmua, fileerin jälkeen 3 solmua - kaikki on siistiä.
Olemme menettäneet joitakin tietoja. Ja meidän on ymmärrettävä, kuinka paljon olemme menettäneet. Etsimme juuri sitä hetkeä, jolloin kelaamme taaksepäin. Löydämme sen sellaisista päiväkirjamerkinnöistä. Rewind alkoi, teki jotain siellä ja päättyi.
Meidän on löydettävä tapahtumalokista paikka, johon vanha mestari lopetti. Tässä tapauksessa tämä on merkki. Ja tarvitsemme toisen merkin, eli etäisyyden, jolla vanha mestari eroaa uudesta.
Otamme tavallisen pg_wal_lsn_diff ja vertaamme näitä kahta arvoa. Ja tässä tapauksessa saamme 17 megatavua. Paljon vai vähän, jokainen päättää itse. Koska jollekin 17 megatavua ei ole paljon, jollekin se on paljon ja mahdotonta hyväksyä. Täällä jokainen päättää itse yrityksen tarpeiden mukaan.
Mutta mitä olemme havainneet itse?
Ensinnäkin meidän on päätettävä itse – tarvitsemmeko aina Patronin automaattisen käynnistyksen järjestelmän uudelleenkäynnistyksen jälkeen? Usein käy niin, että meidän täytyy mennä vanhan mestarin luo katsomaan, kuinka pitkälle hän on mennyt. Ehkä tarkasta tapahtumalokin segmentit ja katso mitä siellä on. Ja ymmärtääksemme, voimmeko kadottaa nämä tiedot vai onko meidän suoritettava vanha isäntä itsenäisessä tilassa, jotta voimme vetää nämä tiedot ulos.
Ja vasta sen jälkeen meidän on päätettävä, voimmeko hylätä nämä tiedot vai voimmeko palauttaa ne, yhdistää tämä solmu replikana klusteriimme.
Lisäksi on parametri "maximum_lag_on_failover". Oletuksena, jos muistini ei petä, tämän parametrin arvo on 1 megatavu.
Miten hän toimii? Jos replikamme on jäljessä 1 megatavun dataa jäljessä replikointiviiveessä, tämä replika ei osallistu vaaleihin. Ja jos yhtäkkiä tapahtuu fileover, Patroni katsoo, mitkä jäljennökset ovat jäljessä. Jos he ovat takana suurella määrällä tapahtumalokeja, he eivät voi tulla mestariksi. Tämä on erittäin hyvä suojausominaisuus, joka estää sinua menettämästä paljon tietoja.
Mutta ongelmana on se, että Patroni-klusterin ja DCS:n replikointiviive päivitetään tietyin väliajoin. Mielestäni 30 sekuntia on oletusarvoinen ttl-arvo.
Vastaavasti voi olla tilanne, jossa DCS:ssä on yksi replikointiviive replikoilla, mutta itse asiassa voi olla täysin erilainen viive tai viivettä ei välttämättä ole ollenkaan, eli tämä asia ei ole reaaliaikainen. Eikä se aina heijasta todellista kuvaa. Eikä siinä kannata tehdä hienoa logiikkaa.
Ja menetyksen riski on aina olemassa. Ja pahimmassa tapauksessa yksi kaava ja keskimääräisessä tapauksessa toinen kaava. Eli kun suunnittelemme Patronin käyttöönottoa ja arvioimme, kuinka paljon dataa voimme menettää, meidän täytyy luottaa näihin kaavoihin ja suunnilleen kuvitella, kuinka paljon dataa voimme menettää.
Ja hyviä uutisia on. Kun vanha mestari on mennyt eteenpäin, hän voi mennä eteenpäin joidenkin taustaprosessien takia. Eli siellä oli jonkinlainen tyhjiö, hän kirjoitti tiedot, tallensi ne tapahtumalokiin. Ja voimme helposti jättää huomiotta ja menettää nämä tiedot. Tässä ei ole ongelmaa.
Ja tältä lokit näyttävät, jos max_lag_on_failover on asetettu ja tiedosto on tapahtunut ja sinun on valittava uusi isäntä. Jäljennös arvioi itsensä kyvyttömäksi osallistumaan vaaleihin. Ja hän kieltäytyy osallistumasta kilpailuun johtajasta. Ja hän odottaa, että uusi mestari valitaan, jotta hän voi sitten muodostaa yhteyden siihen. Tämä on lisätoimenpide tietojen häviämistä vastaan.
Täällä meillä on tuotetiimi, joka kirjoitti, että heidän tuotteellaan on ongelmia Postgresin kanssa. Samanaikaisesti itse isäntäkoneeseen ei pääse käsiksi, koska se ei ole käytettävissä SSH:n kautta. Ja automaattinen tiedosto ei myöskään tapahdu.
Tämä isäntä pakotettiin käynnistymään uudelleen. Uudelleenkäynnistyksen vuoksi tapahtui automaattinen tiedosto, vaikka oli mahdollista tehdä manuaalinen automaattinen tiedosto, kuten nyt ymmärrän. Ja uudelleenkäynnistyksen jälkeen aiomme jo nähdä, mitä meillä oli nykyisen mestarin kanssa.
Samalla tiesimme etukäteen, että meillä on ongelmia levyjen kanssa, eli tiesimme jo seurannasta, mistä kaivetaan ja mitä etsiä.
Pääsimme postgres-lokiin, aloimme nähdä mitä siellä tapahtui. Näimme sitoumuksia, jotka kestävät siellä yhden, kaksi, kolme sekuntia, mikä ei ole ollenkaan normaalia. Näimme, että tyhjiömme käynnistyy hyvin hitaasti ja oudosti. Ja näimme väliaikaiset tiedostot levyllä. Tämä tarkoittaa, että nämä ovat kaikki osoittimia levy-ongelmista.
Tutkimme järjestelmän dmesg (ytimen loki). Ja näimme, että meillä on ongelmia yhden levyn kanssa. Levyalijärjestelmä oli ohjelmisto Raid. Katsoimme /proc/mdstat ja huomasimme, että meiltä puuttui yksi asema. Eli on 8 levyn raid, meiltä puuttuu yksi. Jos tarkastelet diaa huolellisesti, tulosteessa näet, että meillä ei ole siellä sde:tä. Meillä levy on ehdollisesti pudonnut. Tämä aiheutti levyongelmia, ja myös sovellukset kokivat ongelmia työskennellessään Postgres-klusterin kanssa.
Ja tässä tapauksessa Patroni ei auttaisi meitä millään tavalla, koska Patronin tehtävänä ei ole valvoa palvelimen tilaa, levyn tilaa. Ja meidän on seurattava tällaisia tilanteita ulkopuolisella valvonnalla. Lisäsimme nopeasti levyvalvonnan ulkoiseen valvontaan.
Ja siellä oli sellainen ajatus - voisiko miekkailu- tai vahtikoiraohjelmisto auttaa meitä? Ajattelimme, että hän tuskin olisi auttanut meitä tässä tapauksessa, koska ongelmien aikana Patroni jatkoi vuorovaikutusta DCS-klusterin kanssa eikä nähnyt mitään ongelmaa. Eli DCS:n ja Patronin näkökulmasta kaikki oli kunnossa klusterin kanssa, vaikka itse asiassa levyssä oli ongelmia, tietokannan saatavuudessa oli ongelmia.
Tämä on mielestäni yksi oudoimmista ongelmista, joita olen tutkinut hyvin pitkään, olen lukenut paljon lokeja, poiminut uudelleen ja kutsunut sitä klusterisimulaattoriksi.
Ongelmana oli, että vanhasta isännästä ei voinut tulla normaalia replikaa, eli Patroni aloitti sen, Patroni osoitti, että tämä solmu oli läsnä kopiona, mutta samalla se ei ollut normaali kopio. Nyt näet miksi. Tämä on se, mitä olen salannut tämän ongelman analysoinnista.
Ja miten kaikki alkoi? Se alkoi, kuten edellisessä ongelmassa, levyjarruilla. Meillä oli sitoumuksia sekunniksi, kahdeksi.
Yhteyksissä oli katkoksia, eli asiakkaita repeytyi.
Tukkeumia oli eri vakavuudeltaan.
Ja vastaavasti levyalijärjestelmä ei ole kovin herkkä.
Ja mysteerisin asia minulle on välitön sammutuspyyntö, joka saapui. Postgresilla on kolme sammutustilaa:
- On hienoa, kun odotamme, että kaikki asiakkaat katkaisevat yhteyden itse.
- On nopeaa, kun pakotamme asiakkaat katkaisemaan yhteyden, koska aiomme sulkea.
- Ja välittömästi. Tässä tapauksessa välitön ei edes käske asiakkaita sammuttamaan, se vain sammuu ilman varoitusta. Ja kaikille asiakkaille käyttöjärjestelmä lähettää jo RST-sanoman (TCP-sanoman, että yhteys on katkennut eikä asiakkaalla ole enää mitään pyydettävää).
Kuka lähetti tämän signaalin? Postgres-taustaprosessit eivät lähetä tällaisia signaaleja toisilleen, eli tämä on kill-9. He eivät lähetä tällaisia asioita toisilleen, he vain reagoivat sellaisiin, eli tämä on Postgresin hätäkäynnistys. Kuka sen lähetti, en tiedä.
Katsoin "viimeistä" komentoa ja näin yhden henkilön, joka myös kirjautui tälle palvelimelle kanssamme, mutta olin liian ujo kysyäkseni kysymystä. Ehkä se oli tappaa -9. Näkisin tappaa -9 lokeissa, koska Postgres sanoo, että se kesti tappaa -9, mutta en nähnyt sitä lokeissa.
Katsoessani pidemmälle huomasin, että Patroni ei kirjoittanut lokiin melko pitkään - 54 sekuntia. Ja jos vertaamme kahta aikaleimaa, viestejä ei ollut noin 54 sekuntiin.
Ja tänä aikana oli automaattinen tiedosto. Patroni teki täällä taas hienoa työtä. Vanha mestarimme ei ollut tavoitettavissa, hänelle tapahtui jotain. Ja uuden mestarin valinta alkoi. Täällä kaikki toimi hyvin. Meidän pgsql01 on tullut uusi johtaja.
Meillä on kopio, josta on tullut mestari. Ja on toinen vastaus. Ja toisen replikan kanssa oli ongelmia. Hän yritti konfiguroida uudelleen. Ymmärtääkseni hän yritti muuttaa recovery.conf-tiedostoa, käynnistää Postgresin uudelleen ja muodostaa yhteyden uuteen masteriin. Hän kirjoittaa viestejä 10 sekunnin välein, että hän yrittää, mutta hän ei onnistu.
Ja näiden yritysten aikana vanhalle isännälle saapuu välittömän sammutuksen signaali. Master käynnistetään uudelleen. Ja myös palautuminen pysähtyy, koska vanha mestari käynnistyy uudelleen. Toisin sanoen replika ei voi muodostaa yhteyttä siihen, koska se on sammutustilassa.
Jossain vaiheessa se toimi, mutta replikointi ei alkanut.
Ainoa veikkaukseni on, että recovery.conf:ssa oli vanha pääosoite. Ja kun uusi isäntä ilmestyi, toinen kopio yritti silti muodostaa yhteyden vanhaan isäntään.
Kun Patroni käynnisti toisen replikan, solmu käynnistyi, mutta ei voinut replikoida. Ja muodostui replikointiviive, joka näytti suunnilleen tältä. Eli kaikki kolme solmua olivat paikoillaan, mutta toinen solmu jäi jälkeen.
Samanaikaisesti, jos katsot kirjoitettuja lokeja, voit nähdä, että replikointi ei voinut käynnistyä, koska tapahtumalokit olivat erilaisia. Ja isäntälaitteen tarjoamat tapahtumalokit, jotka on määritetty recovery.conf:ssa, eivät yksinkertaisesti sovi nykyiseen solmuun.
Ja tässä tein virheen. Minun piti tulla katsomaan, mitä recovery.conf sisältää testatakseni hypoteesiani, että olimme yhteydessä väärään isäntään. Mutta sitten olin vain tekemisissä tämän asian kanssa, eikä se tullut mieleeni, tai näin, että kopio oli jäljessä ja se piti täyttää uudelleen, eli tein jotenkin huolimattomasti töitä. Tämä oli minun yhteisni.
30 minuutin kuluttua järjestelmänvalvoja tuli jo, eli käynnistin Patronin uudelleen kopiossa. Tein jo lopun sille, ajattelin, että se pitäisi täyttää uudelleen. Ja ajattelin - käynnistän Patronin uudelleen, ehkä jotain hyvää tulee. Toipuminen alkoi. Ja tukikohta jopa avautui, se oli valmis vastaanottamaan yhteyksiä.
Replikointi on alkanut. Mutta minuuttia myöhemmin hän putosi virheeseen, jonka mukaan tapahtumalokit eivät sovellu hänelle.
Ajattelin käynnistää uudestaan. Käynnistin Patronin uudelleen, enkä Postgresia uudelleen, vaan Patroni uudelleen siinä toivossa, että se käynnistäisi tietokannan maagisesti.
Replikointi alkoi uudelleen, mutta tapahtumalokin merkit olivat erilaiset, ne eivät olleet samat kuin edellisessä käynnistysyrityksessä. Replikointi pysähtyi taas. Ja viesti oli jo hieman erilainen. Ja se ei ollut minulle kovin informatiivinen.
Ja sitten minulle tulee mieleen - entä jos käynnistän Postgresin uudelleen, tällä hetkellä teen tarkistuspisteen nykyiselle isännälle siirtääkseni tapahtumalokin kohtaa hieman eteenpäin, jotta palautuminen alkaa toisesta hetkestä? Lisäksi meillä oli vielä WAL-varastoja.
Käynnistin Patronin uudelleen, tein pari tarkistuspistettä isännällä, pari uudelleenkäynnistyspistettä replikalla sen avautuessa. Ja se auttoi. Mietin pitkään, miksi se auttoi ja miten se toimi. Ja replika alkoi. Ja replikaatio ei enää repeytynyt.
Tällainen ongelma on minulle yksi mysteerisimmistä, jonka yli vieläkin mietin, mitä siellä oikein tapahtui.
Mitä vaikutuksia tässä on? Patroni voi toimia suunnitellusti ja ilman virheitä. Mutta samalla tämä ei ole 100 %:n takuu siitä, että meillä on kaikki hyvin. Replika voi käynnistyä, mutta se voi olla puoliksi toimivassa tilassa, eikä sovellus voi toimia sellaisen replikan kanssa, koska siellä on vanhaa dataa.
Ja arkistoinnin jälkeen sinun on aina tarkistettava, että klusterin kanssa on kaikki kunnossa, eli että replikoita on tarvittava määrä, replikointiviivettä ei ole.
Ja kun käsittelemme näitä asioita, annan suosituksia. Yritin yhdistää ne kahdeksi diaksi. Todennäköisesti kaikki tarinat voitaisiin yhdistää kahdeksi diaksi ja vain kertoa.
Kun käytät Patronia, sinulla on oltava valvonta. Sinun pitäisi aina tietää, milloin automaattinen tiedostonvaihto tapahtui, koska jos et tiedä, että sinulla oli automaattinen tiedostonvaihto, et voi hallita klusteria. Ja se on huono.
Jokaisen tiedostolaitteen jälkeen meidän on aina tarkistettava klusteri manuaalisesti. Meidän on varmistettava, että meillä on aina ajantasainen määrä replikoita, replikointiviivettä ei ole, lokeissa ei ole virheitä, jotka liittyvät suoratoistoon, Patronilla, DCS-järjestelmällä.
Automaatio voi toimia hyvin, Patroni on erittäin hyvä työkalu. Se voi toimia, mutta tämä ei vie klusteria haluttuun tilaan. Ja jos emme saa siitä selvää, joudumme vaikeuksiin.
Ja Patroni ei ole hopealuoti. Meidän on vielä ymmärrettävä, miten Postgres toimii, kuinka replikointi toimii ja kuinka Patroni toimii Postgresin kanssa ja kuinka solmujen välinen kommunikaatio on järjestetty. Tämä on välttämätöntä käsien ongelmien korjaamiseksi.
Miten lähestyn diagnoosikysymystä? Kävi niin, että työskentelemme eri asiakkaiden kanssa, eikä kenelläkään ole ELK-pinoa, vaan lokit on järjestettävä avaamalla 6 konsolia ja 2 välilehteä. Yhdessä välilehdessä nämä ovat kunkin solmun Patroni-lokit, toisessa välilehdessä nämä ovat Consul-lokit tai tarvittaessa Postgres. Tätä on erittäin vaikea diagnosoida.
Millaisia lähestymistapoja olen kehittänyt? Ensin katson aina, kun arkisto on saapunut. Ja minulle tämä on vedenjakaja. Katson mitä tapahtui ennen viilaajaa, arkistoinnin aikana ja sen jälkeen. Fileoverissa on kaksi merkkiä: tämä on alkamis- ja lopetusaika.
Seuraavaksi etsin lokeista tiedostoa edeltäneet tapahtumat, eli etsin syitä, miksi arkistointi tapahtui.
Ja tämä antaa kuvan ymmärtämisestä, mitä tapahtui ja mitä voidaan tehdä tulevaisuudessa, jotta tällaisia olosuhteita ei tapahdu (ja seurauksena ei ole tiedostoa).
Ja mistä me yleensä katsomme? Katson:
- Ensinnäkin Patronin lokeihin.
- Seuraavaksi katson Postgres-lokeja tai DCS-lokeja sen mukaan, mitä Patroni-lokeista löytyi.
- Ja järjestelmälokit antavat joskus myös käsityksen siitä, mikä aiheutti arkistoinnin.
Mitä mieltä olen Patronista? Minulla on erittäin hyvä suhde Patroniin. Mielestäni tämä on parasta mitä nykyään on. Tiedän monia muitakin tuotteita. Nämä ovat Stolon, Repmgr, Pg_auto_failover, PAF. 4 työkalua. Kokeilin niitä kaikkia. Patroni on suosikkini.
Jos he kysyvät minulta: "Suosittelenko Patronia?". Sanon kyllä, koska pidän Patronista. Ja luulen oppineeni valmistamaan sen.
Jos olet kiinnostunut näkemään mitä muita ongelmia Patronilla on mainitsemieni ongelmien lisäksi, voit aina käydä katsomassa sivua GitHubissa. Siellä on monia erilaisia tarinoita ja siellä keskustellaan monista mielenkiintoisista aiheista. Tämän seurauksena joitain bugeja otettiin käyttöön ja korjattiin, eli tämä on mielenkiintoista luettavaa.
On mielenkiintoisia tarinoita ihmisistä, jotka ampuvat itseään jalkaan. Erittäin informatiivinen. Luet ja ymmärrät, että sinun ei tarvitse tehdä niin. Tikkasin itseäni.
Ja haluan sanoa suuret kiitokset Zalandolle tämän projektin kehittämisestä, nimittäin Alexander Kukushkinille ja Aleksei Klyukinille. Aleksey Klyukin on yksi kirjoittajista, hän ei enää työskentele Zalandolla, mutta nämä ovat kaksi henkilöä, jotka aloittivat työskentelyn tämän tuotteen kanssa.
Ja mielestäni Patroni on erittäin siisti asia. Olen iloinen, että hän on olemassa, hänen kanssaan on mielenkiintoista. Ja iso kiitos kaikille avustajille, jotka kirjoittavat Patronille korjaustiedostoja. Toivon, että Patronista tulee kypsempi, viileämpi ja tehokkaampi iän myötä. Se on jo toimiva, mutta toivottavasti siitä tulee vielä parempi. Siksi, jos aiot käyttää Patronia, älä pelkää. Tämä on hyvä ratkaisu, se voidaan toteuttaa ja käyttää.
Siinä kaikki. Jos sinulla on kysyttävää, kysy.
kysymykset
Kiitos raportista! Jos viilaajan jälkeen pitää vielä katsoa sinne erittäin tarkasti, niin miksi tarvitsemme automaattista viilaajaa?
Koska se on uutta. Olemme olleet hänen kanssaan vasta vuoden. Parempi olla turvassa. Haluamme tulla sisään ja nähdä, että kaikki todella meni niin kuin pitää. Tämä on aikuisten epäluottamuksen taso - on parempi tarkistaa ja nähdä.
Menimme esimerkiksi aamulla katsomaan, eikö niin?
Ei aamulla, yleensä saamme tietää autotiedostosta lähes välittömästi. Saamme ilmoituksia, näemme, että automaattinen tiedosto on tapahtunut. Melkein heti mennään katsomaan. Mutta kaikki nämä tarkastukset olisi saatettava valvontatasolle. Jos käytät Patronia REST API:n kautta, sinulla on historia. Historiasta näet aikaleimat, jolloin tiedosto tapahtui. Tämän perusteella voidaan tehdä seurantaa. Näet historian, kuinka monta tapahtumaa siellä oli. Jos meillä on enemmän tapahtumia, automaattinen tiedosto on tapahtunut. Voit mennä katsomaan. Tai valvontaautomaatiomme tarkisti, että meillä on kaikki kopiot paikoillaan, ei ole viivettä ja kaikki on kunnossa.
Kiitos!
Kiitos paljon hienosta tarinasta! Jos siirsimme DCS-klusterin jonnekin kauas Postgres-klusterista, pitääkö tämäkin klusteri huoltaa säännöllisesti? Mitkä ovat parhaat käytännöt, joiden mukaan jotkin DCS-klusterin osat on kytkettävä pois päältä, jotain tekemistä niiden kanssa jne.? Miten tämä koko rakenne säilyy? Ja miten teet nämä asiat?
Yhdelle yritykselle oli tarpeen tehdä matriisi ongelmista, mitä tapahtuu, jos jokin komponenteista tai useampi komponentti epäonnistuu. Tämän matriisin mukaan käymme peräkkäin läpi kaikki komponentit ja rakennamme skenaarioita näiden komponenttien epäonnistumisen varalta. Vastaavasti jokaiselle vikaskenaariolle voi olla toimintasuunnitelma palautumista varten. Ja DCS:n tapauksessa se tulee osana vakioinfrastruktuuria. Ja järjestelmänvalvoja hallinnoi sitä, ja luotamme jo sitä hallinnoiviin ylläpitäjiin ja heidän kykyynsä korjata se onnettomuustapauksissa. Jos DCS:ää ei ole ollenkaan, otamme sen käyttöön, mutta samalla emme erityisesti valvo sitä, koska emme ole vastuussa infrastruktuurista, mutta annamme suosituksia kuinka ja mitä valvoa.
Eli ymmärsinkö oikein, että minun on poistettava Patroni käytöstä, poistettava tiedostot ja poistettava kaikki käytöstä ennen kuin teen mitään isäntien kanssa?
Se riippuu siitä, kuinka monta solmua meillä on DCS-klusterissa. Jos solmuja on useita ja jos poistamme käytöstä vain yhden solmuista (replikan), klusteri ylläpitää päätösvaltaisuutta. Ja Patroni on edelleen toiminnassa. Eikä mikään laukea. Jos meillä on monimutkaisia toimintoja, jotka vaikuttavat useampaan solmuun, joiden puuttuminen voi pilata päätösvaltaisuuden, niin - kyllä, voi olla järkevää laittaa Patroni tauolle. Siinä on vastaava komento - patronictl pause, patronictl resume. Pidämme vain tauon ja automaattinen suodatin ei toimi tuolloin. Huollamme DCS-klusteria, sitten otamme tauon pois ja jatkamme elämää.
Kiitos paljon!
Kiitos paljon raportistasi! Miltä tuotetiimi suhtautuu tietojen katoamisesta?
Tuotetiimit eivät välitä, ja tiimien johtajat ovat huolissaan.
Mitä takuita on olemassa?
Takuut ovat erittäin vaikeita. Alexander Kukushkinilla on raportti "Kuinka laskea RPO ja RTO", eli palautumisaika ja kuinka paljon tietoja voimme menettää. Mielestäni meidän on löydettävä nämä diat ja tutkittava niitä. Sikäli kuin muistan, näiden asioiden laskemiseen on tiettyjä vaiheita. Kuinka monta tapahtumaa voimme menettää, kuinka paljon tietoja voimme menettää. Vaihtoehtoisesti voimme käyttää synkronista replikointia Patroni-tasolla, mutta tämä on kaksiteräinen miekka: joko meillä on tietojen luotettavuus tai menetämme nopeuden. Synkroninen replikointi on olemassa, mutta se ei myöskään takaa 100-prosenttista suojaa tietojen katoamista vastaan.
Aleksei, kiitos hienosta raportista! Onko kokemuksia Patronin käytöstä nollatasoisen suojauksen aikaansaamiseksi? Eli synkronisen valmiustilan yhteydessä? Tämä on ensimmäinen kysymys. Ja toinen kysymys. Olet käyttänyt erilaisia ratkaisuja. Käytimme Repmgr:ää, mutta ilman autofileria, ja nyt aiomme sisällyttää autofilerin. Ja pidämme Patronia vaihtoehtoisena ratkaisuna. Mitä voit sanoa eduksi Repmgriin verrattuna?
Ensimmäinen kysymys koski synkronisia kopioita. Kukaan ei käytä täällä synkronista replikointia, koska kaikki ovat peloissaan (useat asiakkaat käyttävät sitä jo, periaatteessa he eivät huomanneet suorituskykyongelmia - Puhujan huomautus). Mutta olemme kehittäneet itsellemme säännön, että synkronisessa replikointiklusterissa tulee olla vähintään kolme solmua, koska jos meillä on kaksi solmua ja jos isäntä tai replika epäonnistuu, Patroni vaihtaa tämän solmun Standalone-tilaan, jotta sovellus jatkaa tehdä työtä. Tässä tapauksessa on olemassa tietojen menettämisen vaara.
Mitä tulee toiseen kysymykseen, olemme käyttäneet Repmgr:ää ja käytämme edelleen joidenkin asiakkaiden kanssa historiallisista syistä. Mitä voidaan sanoa? Patronin mukana tulee automaattinen suodatin, Repmgr sisältää lisäominaisuuden, joka on otettava käyttöön. Meidän on suoritettava Repmgr-daemon jokaisessa solmussa ja sitten voimme määrittää automaattisen tiedoston.
Repmgr tarkistaa, ovatko Postgres-solmut elossa. Repmgr-prosessit tarkistavat toistensa olemassaolon, tämä ei ole kovin tehokas lähestymistapa. verkon eristäminen voi olla monimutkaisia tapauksia, joissa suuri Repmgr-klusteri voi hajota useiksi pienemmiksi ja jatkaa toimintaansa. En ole seurannut Repmgriä pitkään aikaan, ehkä se korjattiin ... tai ehkä ei. Mutta klusterin tilaa koskevien tietojen poistaminen DCS:stä, kuten Stolon, Patroni tekee, on toteuttamiskelpoisin vaihtoehto.
Alexey, minulla on kysymys, ehkä lievempi. Yhdessä ensimmäisistä esimerkeistä siirsit DCS:n paikalliselta koneelta etäisäntään. Ymmärrämme, että verkko on asia, jolla on omat ominaisuutensa, se elää omillaan. Ja mitä tapahtuu, jos DCS-klusteri ei jostain syystä ole käytettävissä? En sano syitä, niitä voi olla monia: verkostoituneiden kieroista käsistä todellisiin ongelmiin.
En sanonut sitä ääneen, mutta DCS-klusterin on myös oltava vikasietoinen, eli se on pariton määrä solmuja, jotta päätösvaltaisuus täyttyisi. Mitä tapahtuu, jos DCS-klusteri ei ole käytettävissä tai päätösvaltaisuus ei täyty, eli jokin verkkojako tai solmuvika? Tässä tapauksessa Patroni-klusteri siirtyy vain luku -tilaan. Patroni-klusteri ei voi määrittää klusterin tilaa ja mitä tehdä. Se ei voi ottaa yhteyttä DCS:ään ja tallentaa uutta klusterin tilaa sinne, joten koko klusteri siirtyy vain luku -tilaan. Ja odottaa joko käyttäjän manuaalista puuttumista tai DCS:n palautumista.
Karkeasti ottaen DCS:stä tulee meille yhtä tärkeä palvelu kuin itse tukikohta?
Kyllä kyllä. Niin monissa nykyaikaisissa yrityksissä Service Discovery on olennainen osa infrastruktuuria. Se on otettu käyttöön jo ennen kuin infrastruktuurissa oli edes tietokanta. Suhteellisesti sanottuna infrastruktuuri käynnistettiin, otettiin käyttöön DC:ssä, ja meillä on heti Service Discovery. Jos se on Consul, DNS voidaan rakentaa sen päälle. Jos tämä on Etcd, Kubernetes-klusterissa saattaa olla osa, jossa kaikki muu otetaan käyttöön. Minusta tuntuu, että Service Discovery on jo olennainen osa nykyaikaisia infrastruktuureja. Ja he ajattelevat sitä paljon aikaisemmin kuin tietokantoja.
Kiitos!
Lähde: will.com