Andrey Borodin kertoo raportissaan, kuinka he ottivat huomioon PgBouncerin skaalaamisen kokemuksen, kun suunniteltiin yhteysvaraajaa. , kun he ottivat sen tuotantoon. Lisäksi keskustelemme siitä, mitä vetolaitteen toimintoja haluaisimme nähdä uusissa versioissa: meille on tärkeää paitsi tarpeidemme täyttäminen myös käyttäjäyhteisön kehittäminen .
Video:
Hei kaikki! Minun nimeni on Andrew.
Yandexissä kehitän avoimen lähdekoodin tietokantoja. Ja tänään meillä on aihe Connection Pooler -yhteyksistä.
Jos tiedät kuinka soittaa yhteyspooleriin venäjäksi, kerro minulle. Haluan todella löytää hyvän teknisen termin, joka pitäisi vakiinnuttaa teknisessä kirjallisuudessa.
Aihe on varsin monimutkainen, koska monissa tietokannoissa yhteysvaraaja on sisäänrakennettu eikä siitä tarvitse edes tietää. Tietysti kaikkialla on joitain asetuksia, mutta Postgresissa se ei toimi näin. Ja rinnakkain (HighLoad++ 2019) on Nikolai Samokhvalovin raportti kyselyjen asettamisesta Postgresissa. Ja ymmärtääkseni tänne tuli ihmisiä, jotka olivat jo konfiguroineet kyselynsä täydellisesti, ja nämä ovat ihmisiä, jotka kohtaavat harvinaisempia verkkoon ja resurssien käyttöön liittyviä järjestelmäongelmia. Ja joissain paikoissa se voi olla melko vaikeaa siinä mielessä, että ongelmat eivät ole ilmeisiä.
Yandexillä on Postgres. Monet Yandex-palvelut sijaitsevat Yandex.Cloudissa. Ja meillä on useita petatavuja tietoa, joka tuottaa vähintään miljoona pyyntöä sekunnissa Postgresissa.
Ja tarjoamme melko standardin klusterin kaikille palveluille - tämä on solmun tärkein ensisijainen solmu, tavalliset kaksi kopiota (synkroninen ja asynkroninen), varmuuskopiointi, replikan lukupyyntöjen skaalaus.
Jokainen klusterisolmu on Postgres, johon on asennettu Postgresin ja valvontajärjestelmien lisäksi myös yhteysvaraaja. Connection pooleria käytetään aitaukseen ja sen päätarkoitukseen.
Mikä on yhteyspoolerin päätarkoitus?
Postgres ottaa käyttöön prosessimallin työskennellessään tietokannan kanssa. Tämä tarkoittaa, että yksi yhteys on yksi prosessi, yksi Postgres-taustajärjestelmä. Ja tässä taustaohjelmassa on paljon erilaisia välimuistia, jotka ovat melko kalliita tehdä erilaisia eri yhteyksille.
Lisäksi Postgres-koodissa on taulukko nimeltä procArray. Se sisältää perustiedot verkkoyhteyksistä. Ja melkein kaikilla procArray-käsittelyalgoritmeilla on lineaarinen monimutkaisuus; ne toimivat koko verkkoyhteyksien joukossa. Se on melko nopea sykli, mutta kun verkkoyhteyksiä on enemmän, asiat tulevat hieman kalliimmaksi. Ja kun asiat tulevat hieman kalliimmaksi, voit joutua maksamaan erittäin korkean hinnan monista verkkoyhteyksistä.
On 3 mahdollista lähestymistapaa:
- Sovelluksen puolella.
- Tietokannan puolella.
- Ja välillä, eli kaikenlaisia yhdistelmiä.
Valitettavasti sisäänrakennettu pooli on parhaillaan kehitteillä. Ystävämme PostgreSQL Professionalissa tekevät tämän enimmäkseen. Milloin se ilmestyy, on vaikea ennustaa. Ja itse asiassa meillä on kaksi ratkaisua, joista arkkitehti voi valita. Nämä ovat sovelluspuolen pooli ja välityspalvelinpooli.
Sovelluspuolen allas on helpoin tapa. Ja melkein kaikki asiakasohjaimet tarjoavat sinulle tavan: esittele miljoonat yhteydet koodissa useana kymmeninä yhteyksinä tietokantaan.
Ongelmana on se, että jossain vaiheessa haluat skaalata taustaa, haluat ottaa sen käyttöön monissa virtuaalikoneissa.
Sitten huomaat, että sinulla on useita lisää käytettävyysalueita, useita datakeskuksia. Ja asiakaspuolen yhdistäminen johtaa suurempiin määriin. Suuret ovat noin 10 000 yhteyttä. Tämä on reuna, joka voi toimia normaalisti.
Jos puhumme välityspalvelinten yhdistäjistä, on kaksi poolia, jotka voivat tehdä monia asioita. He eivät ole vain poolaajia. Ne ovat pooleja + enemmän hienoja toimintoja. Tämä и .
Mutta valitettavasti kaikki eivät tarvitse tätä lisätoimintoa. Ja se johtaa siihen, että poolaajat tukevat vain istuntojen yhdistämistä, eli yhtä saapuvaa asiakasta ja yhtä lähtevää asiakasta tietokantaan.
Tämä ei ole kovin sopiva meidän tarkoituksiin, joten käytämme PgBounceria, joka toteuttaa tapahtumien yhdistämisen, eli palvelinyhteydet sovitetaan asiakasyhteyksiin vain tapahtuman ajaksi.
Ja meidän työmäärässämme tämä on totta. Mutta on olemassa muutamia ongelmia.
Ongelmat alkavat, kun haluat diagnosoida istunnon, koska kaikki saapuvat yhteytesi ovat paikallisia. Kaikilla tuli loopback ja jotenkin on vaikea jäljittää istunnon.
Tietenkin voit käyttää sovelluksen_nimi_add_host. Tämä on Bouncer-puolen tapa lisätä IP-osoite kohtaan Application_name. Mutta sovelluksen_nimi määrittää lisäyhteys.
Tässä kaaviossa keltainen viiva on todellisia pyyntöjä ja missä sininen pyyntöjä, jotka lentävät tietokantaan. Ja tämä ero on juuri sovelluksen_nimi asennus, jota tarvitaan vain jäljittämiseen, mutta se ei ole ollenkaan ilmainen.
Lisäksi Bouncerissa et voi rajoittaa yhtä poolia eli tietokantayhteyksien määrää tiettyä käyttäjää kohti tiettyä tietokantaa kohti.
Mihin tämä johtaa? Sinulla on ladattu palvelu, joka on kirjoitettu C++:lla ja jossain lähellä pieni palvelu solmussa, joka ei tee mitään kauheaa tietokannan kanssa, mutta sen ajuri menee hulluksi. Se avaa 20 000 yhteyttä ja kaikki muu odottaa. Jopa koodisi on normaali.
Kirjoitimme tietysti Bouncerille pienen korjaustiedoston, joka lisäsi tämän asetuksen eli rajoitti asiakkaita pooliin.
Tämä olisi mahdollista tehdä Postgresin puolella, eli rajoittaa tietokannan rooleja yhteyksien määrällä.
Mutta sitten menetät kyvyn ymmärtää, miksi sinulla ei ole yhteyksiä palvelimeen. PgBouncer ei anna yhteysvirhettä, se palauttaa aina samat tiedot. Etkä voi ymmärtää: ehkä salasanasi on muuttunut, ehkä tietokanta vain kadonnut, ehkä jotain on vialla. Mutta diagnoosia ei ole. Jos istuntoa ei voida muodostaa, et tiedä, miksi sitä ei voida muodostaa.
Jossain vaiheessa katsot sovelluskaavioita ja huomaat, että sovellus ei toimi.
Katso yläosaa ja huomaa, että Bouncer on yksisäikeinen. Tämä on käännekohta palvelun elämässä. Ymmärrät, että valmistauduit skaalaamaan tietokantaa puolessatoista vuodessa, ja sinun täytyy skaalata pooli.
Olemme tulleet siihen tulokseen, että tarvitsemme lisää PgBouncereita.
Bounceria on hieman korjattu.
Ja he tekivät sen niin, että useita Bouncereita voitiin nostaa käyttämällä uudelleen TCP-porttia. Ja käyttöjärjestelmä siirtää automaattisesti saapuvat TCP-yhteydet niiden välillä käyttämällä kiertokulkua.
Tämä on asiakkaille läpinäkyvää, mikä tarkoittaa, että sinulla näyttää olevan yksi Bouncer, mutta käytössäsi olevat Bouncerit ovat hajanaisia.
Ja tietyllä hetkellä saatat huomata, että nämä 3 Bounceria syövät kukin ytimensä 100%. Tarvitset melkoisen määrän Bouncereita. Miksi?
Koska sinulla on TLS. Sinulla on salattu yhteys. Ja jos vertailet Postgresia TLS:n kanssa ja ilman, huomaat, että muodostettujen yhteyksien määrä putoaa lähes kaksi kertaluokkaa salauksen ollessa käytössä, koska TLS-kättely kuluttaa suorittimen resursseja.
Ja yläosassa näet useita salaustoimintoja, jotka suoritetaan saapuvien yhteyksien aallon aikana. Koska ensisijaisuutemme voi vaihtaa käytettävyysvyöhykkeiden välillä, saapuvien yhteyksien aalto on melko tyypillinen tilanne. Eli jostain syystä vanha ensisijainen ei ollut käytettävissä, koko kuorma lähetettiin toiseen datakeskukseen. He kaikki tulevat tervehtimään TLS:ää samaan aikaan.
Ja suuri määrä TLS-kättelyjä ei ehkä enää tervehdi Bounceria, vaan puristaa hänen kurkkuaan. Aikakatkaisun vuoksi saapuvien yhteyksien aalto saattaa vaimentua. Jos yrität uudelleen tukikohtaan ilman eksponentiaalista perääntymistä, ne eivät tule uudestaan ja uudestaan koherentissa aallossa.
Tässä on esimerkki 16 PgBouncerista, jotka lataavat 16 ydintä 100 %:lla.
Pääsimme kaskadiin PgBouncer. Tämä on paras kokoonpano, joka voidaan saavuttaa kuormallamme Bouncerilla. Ulkoisia Bouncereitamme käytetään TCP-kättelyyn, ja sisäisiä Bouncereita käytetään todelliseen yhdistämiseen, jotta ulkoisia yhteyksiä ei pilkkoudu liikaa.
Tässä kokoonpanossa sujuva uudelleenkäynnistys on mahdollista. Voit käynnistää uudelleen kaikki nämä 18 Bounceria yksitellen. Mutta tällaisen kokoonpanon ylläpitäminen on melko vaikeaa. Järjestelmänvalvojat, DevOps ja ihmiset, jotka ovat itse asiassa vastuussa tästä palvelimesta, eivät ole kovin tyytyväisiä tähän järjestelyyn.
Näyttää siltä, että kaikki parannukset voidaan edistää avoimeen lähdekoodiin, mutta Bounceria ei tueta kovin hyvin. Esimerkiksi mahdollisuus ajaa useita PgBouncereita yhdessä portissa otettiin käyttöön kuukausi sitten. Tästä ominaisuudesta tehtiin vetopyyntö useita vuosia sitten.
Tai vielä yksi esimerkki. Postgresissa voit peruuttaa meneillään olevan pyynnön lähettämällä salaisuuden eri yhteyteen ilman tarpeetonta todennusta. Mutta jotkut asiakkaat lähettävät vain TCP-nollauksen, eli ne katkaisevat verkkoyhteyden. Mitä Bouncer tekee? Hän ei tee mitään. Se jatkaa pyynnön toteuttamista. Jos olet saanut valtavan määrän yhteyksiä, jotka ovat luoneet tietokannan pienillä pyynnöillä, pelkkä yhteyden katkaiseminen Bouncerista ei riitä, vaan sinun on myös suoritettava ne pyynnöt, jotka ovat käynnissä tietokannassa.
Tämä on korjattu, eikä tätä ongelmaa ole vielä yhdistetty Bouncerin ylävirtaan.
Ja niin tulimme siihen tulokseen, että tarvitsemme oman yhteyspoolerimme, jota kehitetään, paikataan, jossa ongelmat voidaan korjata nopeasti ja jonka täytyy tietysti olla monisäikeinen.
Päätehtäväksi asetimme monisäikeyden. Meidän on pystyttävä käsittelemään saapuvien TLS-yhteyksien aaltoa hyvin.
Tätä varten meidän piti kehittää erillinen Machinarium-kirjasto, joka on suunniteltu kuvaamaan verkkoyhteyden koneen tiloja peräkkäisenä koodina. Jos katsot libpq-lähdekoodia, näet melko monimutkaisia kutsuja, jotka voivat palauttaa sinulle tuloksen ja sanoa: "Soita minulle myöhemmin. Tällä hetkellä minulla on IO toistaiseksi, mutta kun IO poistuu, minulla on kuormitus prosessoriin." Ja tämä on monitasoinen järjestelmä. Verkkoviestintä kuvataan yleensä tilakoneella. Paljon sääntöjä, kuten "Jos sain aiemmin paketin otsikon, jonka koko on N, nyt odotan N tavua", "Jos lähetin SYNC-paketin, nyt odotan pakettia tulosmetatiedoilla." Tuloksena on melko vaikea, intuitiivinen koodi, ikään kuin sokkelo olisi muutettu viivaskannaukseksi. Teimme sen niin, että tilakoneen sijaan ohjelmoija kuvaa vuorovaikutuksen pääpolun tavallisen pakottavan koodin muodossa. Tässä pakottavassa koodissa on vain lisättävä paikkoja, joissa suoritussekvenssi on keskeytettävä odottamalla tietoja verkosta ja siirtämällä suorituskonteksti toiseen korutiiniin (vihreä säie). Tämä lähestymistapa on samanlainen kuin se, että kirjoitamme sokkelon odotetuin polku peräkkäin ja lisäämme siihen oksia.
Tämän seurauksena meillä on yksi säie, joka hyväksyy TCP:n ja round-robin välittää TPC-yhteyden monille työntekijöille.
Tässä tapauksessa jokainen asiakasyhteys toimii aina yhdellä prosessorilla. Ja tämän avulla voit tehdä siitä välimuistiystävällisen.
Ja lisäksi olemme hieman parantaneet pienten pakettien kokoelmaa yhdeksi suureksi paketiksi keventääksemme järjestelmän TCP-pinoa.
Lisäksi olemme parantaneet tapahtumien yhdistämistä siinä mielessä, että Odyssey voi konfiguroituna lähettää CANCEL ja ROLLBACK verkkoyhteyden katketessa, eli jos kukaan ei odota pyyntöä, Odyssey käskee tietokantaa olemaan yrittämättä täyttää pyynnön, joka saattaa hukata arvokkaita resursseja.
Ja aina kun mahdollista, pidämme yhteyttä samaan asiakkaaseen. Näin vältytään asentamasta sovelluksen_nimi_add_host uudelleen. Jos tämä on mahdollista, meidän ei tarvitse lisäksi nollata diagnostiikkaan tarvittavia parametreja.
Työskentelemme Yandex.Cloudin etujen mukaisesti. Ja jos käytät hallittua PostgreSQL:ää ja olet asentanut yhteysvaraajan, voit luoda loogisen replikoinnin ulospäin, eli jättää meille halutessasi loogisen replikoinnin. Bouncer ei vapauta loogista replikointivirtaa ulkopuolella.
Tämä on esimerkki loogisen replikoinnin määrittämisestä.
Lisäksi meillä on tuki fyysiselle replikaatiolle ulospäin. Pilvessä tämä on tietysti mahdotonta, koska silloin klusteri antaa sinulle liikaa tietoa itsestään. Mutta asennuksissasi, jos tarvitset fyysistä replikointia Odysseyn yhteyspoolerin kautta, tämä on mahdollista.
Odysseyssa on täysin yhteensopiva valvonta PgBouncerin kanssa. Meillä on sama konsoli, joka suorittaa lähes kaikki samat komennot. Jos jotain puuttuu, lähetä vetopyyntö tai ainakin ongelma GitHubissa, niin suoritamme tarvittavat komennot. Mutta meillä on jo PgBouncer-konsolin päätoiminnot.
Ja tietysti meillä on virheiden välitys. Palautamme tietokannan ilmoittaman virheen. Saat tietoa siitä, miksi et ole mukana tietokannassa, etkä vain siitä, että et ole mukana tietokannassa.
Tämä ominaisuus on poistettu käytöstä, jos tarvitset 100 %:n yhteensopivuuden PgBouncerin kanssa. Voimme käyttäytyä samalla tavalla kuin Bouncer, vain varmuuden vuoksi.
suunnittelu
Muutama sana Odyssey-lähdekoodista.
Siellä on esimerkiksi "Tauko / Jatka" -komentoja. Niitä käytetään yleensä tietokannan päivittämiseen. Jos sinun on päivitettävä Postgres, voit keskeyttää sen yhteysvaraajassa, suorittaa pg_upgrade ja jatkaa sitten. Ja asiakkaan puolelta näyttää siltä, että tietokanta vain hidastuu. Yhteisön ihmiset toivat meille tämän toiminnon. Hän ei ole vielä jäässä, mutta pian kaikki on. (Jo jäässä)
- jo jäässä
Lisäksi yksi PgBouncerin uusista ominaisuuksista on tuki SCRAM Authenticationille, jonka myös meille toi henkilö, joka ei työskentele Yandex.Cloudissa. Molemmat ovat monimutkaisia toimintoja ja tärkeitä.
Siksi haluaisin kertoa sinulle, mistä Odyssey on tehty, jos haluat myös kirjoittaa pienen koodin nyt.
Sinulla on Odyssey-lähdekanta, joka perustuu kahteen pääkirjastoon. Kiwi-kirjasto on Postgres-viestiprotokollan toteutus. Toisin sanoen Postgresin alkuperäinen proto 3 on vakioviestejä, joita käyttöliittymät ja taustalaitteet voivat vaihtaa. Ne on toteutettu Kiwi-kirjastossa.
Machinarium-kirjasto on säikeen toteutuskirjasto. Pieni fragmentti tästä Machinariumista on kirjoitettu kokoonpanokielellä. Mutta älä huoli, rivejä on vain 15.
Odyssey-arkkitehtuuri. Siellä on pääkone, jolla korutiinit ovat käynnissä. Tämä kone ottaa vastaan saapuvat TCP-yhteydet ja jakaa ne työntekijöiden kesken.
Usean asiakkaan käsittelijä voi toimia yhden työntekijän sisällä. Pääsäikeessä suoritetaan myös konsoli ja crone-tehtävien käsittely sellaisten yhteyksien poistamiseksi, joita ei enää tarvita poolissa.
Odyssey testataan tavallisella Postgres-testisarjalla. Suoritamme asennus-tarkistuksen Bouncerin kautta ja Odysseyn kautta saamme tyhjä div. On olemassa useita päivämäärän muotoiluun liittyviä testejä, jotka eivät läpäise täsmälleen samalla tavalla Bouncerissa ja Odysseyssa.
Lisäksi on monia ohjaimia, joilla on oma testaus. Ja käytämme heidän testejänsä Odysseyn testaamiseen.
Lisäksi meidän on kaskadikokoonpanomme vuoksi testattava erilaisia nippuja: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, jotta voimme olla varmoja, että jos Odyssey päätyisi johonkin kaskadin osiin, se myös toimii edelleen. kuten odotamme.
harava
Käytämme tuotannossa Odysseya. Ja ei olisi reilua, jos sanoisin, että kaikki vain toimii. Ei, eli kyllä, mutta ei aina. Esimerkiksi tuotannossa kaikki vain toimi, sitten ystävämme PostgreSQL Professionalista tulivat ja sanoivat, että meillä on muistivuoto. Ne todella olivat, me korjasimme ne. Mutta se oli yksinkertainen.
Sitten havaitsimme, että yhteysvaraajalla on saapuvia TLS-yhteyksiä ja lähteviä TLS-yhteyksiä. Ja yhteydet vaativat asiakasvarmenteita ja palvelinvarmenteita.
Bouncer- ja Odyssey-palvelinvarmenteet luetaan uudelleen niiden pcachella, mutta asiakasvarmenteita ei tarvitse lukea uudelleen pcachesta, koska skaalautuva Odysseymme lopulta ajaa tämän varmenteen lukemisen järjestelmän suorituskykyyn. Tämä tuli meille yllätyksenä, koska häneltä ei kestänyt kauan vastustaa. Aluksi se skaalautui lineaarisesti, mutta 20 000 saapuvan samanaikaisen yhteyden jälkeen ongelma paljastui.
Pluggable Authentication Method on kyky todentaa käyttämällä sisäänrakennettuja Lunux-työkaluja. PgBouncerissa se on toteutettu siten, että siellä on erillinen säie, joka odottaa vastausta PAM:lta, ja PgBouncer-pääsäie, joka palvelee nykyistä yhteyttä ja voi pyytää heitä asumaan PAM-säikeessä.
Emme toteuttaneet tätä yhdestä yksinkertaisesta syystä. Meillä on paljon lankoja. Miksi me tarvitsemme tätä?
Tämä voi lopulta aiheuttaa ongelmia, koska jos sinulla on PAM-todennus ja ei-PAM-todennus, suuri PAM-todennusaalto voi viivästyttää merkittävästi ei-PAM-todennusta. Tämä on yksi niistä asioista, joita emme ole korjanneet. Mutta jos haluat korjata sen, voit tehdä tämän.
Toinen harava oli, että meillä on yksi lanka, joka hyväksyy kaikki saapuvat yhteydet. Ja sitten heidät siirretään työntekijöiden joukkoon, jossa TLS-kättely tapahtuu.
Bottom line, jos sinulla on yhtenäinen 20 000 verkkoyhteyden aalto, ne kaikki hyväksytään. Ja asiakaspuolella libpq alkaa raportoida aikakatkaisuista. Oletuksena se näyttää olevan 3 sekuntia.
Jos he kaikki eivät pääse tietokantaan samanaikaisesti, he eivät voi päästä tietokantaan, koska kaikki tämä voidaan kattaa ei-eksponentiaalisella uudelleenyrityksellä.
Tulimme siihen tulokseen, että kopioimme järjestelmän PgBouncerista tänne sillä tosiasialla, että hyväksymme TCP-yhteyksien määrää.
Jos näemme, että hyväksymme yhteyksiä, mutta heillä ei lopulta ole aikaa kättelylle, laitamme ne jonoon, jotta ne eivät tuhlaa CPU-resursseja. Tämä johtaa siihen, että kaikille saapuneille yhteyksille ei välttämättä suoriteta samanaikaista kättelyä. Mutta ainakin joku tulee tietokantaan, vaikka kuorma on melko raskas.
roadmap
Mitä haluaisit nähdä tulevaisuudessa Odysseyssa? Mitä olemme valmiita kehittämään itseämme ja mitä odotamme yhteisöltä?
Elokuussa 2019.
Tältä Odysseyn tiekartta näytti elokuussa:
- Halusimme SCRAM- ja PAM-todennuksen.
- Halusimme välittää lukupyynnöt valmiustilaan.
- Haluaisin online-uudelleenkäynnistyksen.
- Ja mahdollisuus pysähtyä palvelimella.
Puolet tästä etenemissuunnitelmasta on saatu valmiiksi, emmekä me. Ja tämä on hyvä. Joten keskustellaan siitä, mitä on jäljellä, ja lisätään lisää.
? Meillä on kopioita, jotka yksinkertaisesti lämmittävät ilman ilman pyyntöjä. Tarvitsemme niitä tarjoamaan vikasietoa ja vaihtoa. Jos jossakin palvelinkeskuksessa ilmenee ongelmia, haluaisin tehdä niille hyödyllistä työtä. Koska emme voi konfiguroida samoja keskusprosessoreita, samaa muistia eri tavalla, koska muuten replikointi ei toimi.
Periaatteessa Postgresissa 10:stä alkaen on mahdollista määrittää session_attrs yhdistämisen yhteydessä. Voit luetella kaikki yhteydessä olevat tietokantaisännät ja sanoa, miksi siirryt tietokantaan: vain kirjoitus tai luku. Ja kuljettaja itse valitsee luettelosta ensimmäisen isännän, josta hän pitää eniten ja joka täyttää session_attrs-vaatimukset.
Mutta tämän lähestymistavan ongelmana on, että se ei hallitse replikointiviivettä. Sinulla saattaa olla jokin kopio, joka on viivästynyt palvelussasi kohtuuttoman kauan. Mahdollistaaksemme täyden toiminnon lukukyselyjen suorittamisen replikalla, meidän on tuettava Odysseyn kykyä olla suorittamatta, kun sitä ei voida lukea.
Odysseyn täytyy ajoittain mennä tietokantaan ja kysyä replikointietäisyyttä ensisijaisesta. Ja jos se on saavuttanut raja-arvon, älä salli uusia pyyntöjä tietokantaan, kerro asiakkaalle, että sen on aloitettava yhteydet uudelleen ja mahdollisesti valittava toinen isäntä pyyntöjen suorittamiseksi. Näin tietokanta voi nopeasti palauttaa replikointiviiveen ja palata uudelleen vastaamaan pyyntöön.
Toteutukselle on vaikea antaa aikataulua, koska se on avoimen lähdekoodin. Mutta toivon, ei 2,5 vuotta kuten kollegani PgBouncerista. Tämän ominaisuuden haluaisin nähdä Odysseyssa.
. Nyt voit luoda valmistetun lausunnon kahdella tavalla. Ensin voit suorittaa SQL-komennon, nimittäin "valmistettu". Ymmärtääksemme tämän SQL-komennon meidän on opittava ymmärtämään SQL Bouncer-puolella. Tämä olisi ylilyöntiä, koska se on ylilyöntiä, koska tarvitsemme koko jäsentimen. Emme voi jäsentää jokaista SQL-komentoa.
Mutta proto3:ssa on valmis lausunto viestiprotokollatasolla. Ja tämä on paikka, jolloin tieto siitä, että valmisteltu lausunto on luotu, tulee jäsennellyssä muodossa. Ja voisimme tukea ymmärrystä, että jossain palvelinyhteydessä asiakas pyysi luomaan valmiita lausuntoja. Ja vaikka tapahtuma olisi suljettu, meidän on silti säilytettävä yhteys palvelimen ja asiakkaan välillä.
Mutta tässä syntyy ristiriita dialogissa, koska joku sanoo, että sinun on ymmärrettävä millaisia valmisteltuja lausuntoja asiakas loi ja jakaa palvelinyhteys kaikkien asiakkaiden välillä, jotka loivat tämän palvelinyhteyden, eli kuka loi tällaisen valmistetun lausunnon.
Andres Freund sanoi, että jos luoksesi tulee asiakas, joka on jo luonut tällaisen valmistetun lausunnon toisessa palvelinyhteydessä, luo se hänelle. Mutta näyttää hieman väärältä suorittaa kyselyitä tietokannassa asiakkaan sijaan, mutta tietokannan kanssa vuorovaikutusta varten protokollan kirjoittavan kehittäjän näkökulmasta olisi kätevää, jos hänelle annettaisiin yksinkertaisesti verkkoyhteys, jossa on sellainen valmis kysely.
Ja vielä yksi ominaisuus, joka meidän on otettava käyttöön. Meillä on nyt seuranta yhteensopiva PgBouncerin kanssa. Voimme palauttaa keskimääräisen kyselyn suoritusajan. Mutta keskimääräinen aika on sairaalan keskilämpötila: jotkut ovat kylmiä, jotkut ovat lämpimiä - keskimäärin kaikki ovat terveitä. Se ei ole totta.
Meidän on otettava käyttöön tuki prosenttipisteille, jotka osoittaisivat, että on hitaita kyselyitä, jotka tuhlaavat resursseja ja tekevät seurannasta hyväksyttävämpää.
Tärkeintä on, että haluan version 1.0 (versio 1.1 on jo julkaistu). Tosiasia on, että Odyssey on nyt versiossa 1.0rc, eli julkaisuehdokas. Ja kaikki luetteloimani ongelmat korjattiin täsmälleen samalla versiolla, paitsi muistivuoto.
Mitä versio 1.0 tarkoittaa meille? Siirrämme Odysseyn tukikohtiimme. Se on jo käynnissä tietokantoissamme, mutta kun se saavuttaa pisteen 1 000 000 pyyntöä sekunnissa, voimme sanoa, että tämä on julkaisuversio ja tämä on versio, jota voidaan kutsua 1.0:ksi.
Useat yhteisön ihmiset ovat pyytäneet, että versio 1.0 sisältäisi tauon ja SCRAMin. Mutta tämä tarkoittaa, että meidän on otettava seuraava versio tuotantoon, koska SCRAMia tai taukoa ei ole vielä tapettu. Mutta todennäköisesti tämä ongelma ratkaistaan melko nopeasti.
Odotan vetopyyntöäsi. Haluaisin myös kuulla, mitä ongelmia sinulla on Bouncerin kanssa. Keskustellaan niistä. Ehkä voimme toteuttaa joitain tarvitsemiasi toimintoja.
Tämä on osani loppu, haluaisin kuunnella sinua. Kiitos!
kysymykset
Jos määritän oman sovellukseni_nimi, välitetäänkö se oikein, myös Odysseyn tapahtumien yhdistämisessä?
Odyssey vai Bouncer?
Odysseyssa. Bouncerissa se heitetään.
Teemme setin.
Ja jos todellinen yhteyteni hyppää muihin yhteyksiin, välitetäänkö se?
Teemme joukon kaikista luettelossa luetelluista parametreista. En tiedä, onko sovelluksen_nimi tässä luettelossa. Luulen nähneeni hänet siellä. Asetamme kaikki samat parametrit. Yhdellä pyynnöstä laite tekee kaiken, mitä asiakas on asentanut käynnistyksen aikana.
Kiitos, Andrey, raportista! Hyvä raportti! Olen iloinen, että Odyssey kehittyy nopeammin ja nopeammin joka minuutti. Haluan jatkaa näin. Olemme jo pyytäneet sinua muodostamaan usean tietolähteen yhteyden, jotta Odyssey voi muodostaa yhteyden eri tietokantoihin samanaikaisesti eli isäntäorjaan ja muodostaa sitten automaattisesti yhteyden uuteen isäntälaitteeseen vikasietotilan jälkeen.
Kyllä, taidan muistaa tämän keskustelun. Nyt varastoja on useita. Mutta niiden välillä ei ole vaihtoa. Meidän on puolestamme kysyttävä palvelimelta, että se on edelleen elossa, ja ymmärrettävä, että vikasieto on tapahtunut. Kuka kutsuu pg_recoveryä. Minulla on tavallinen tapa ymmärtää, että emme tulleet mestarin luo. Ja pitäisikö meidän ymmärtää jotenkin virheistä vai mitä? Eli idea on mielenkiintoinen, siitä keskustellaan. Kirjoita lisää kommentteja. Jos sinulla on työntekijöitä, jotka osaavat C, niin se on hienoa.
Myös replikoiden skaalaaminen kiinnostaa meitä, koska haluamme tehdä replikoitujen klustereiden käyttöönoton sovelluskehittäjille mahdollisimman yksinkertaiseksi. Mutta tänne haluaisin lisää kommentteja, eli miten se tehdään, miten se tehdään hyvin.
Kysymys koskee myös kopioita. Osoittautuu, että sinulla on mestari ja useita kopioita. Ja on selvää, että he menevät replikaan harvemmin kuin isäntälle yhteyksiä varten, koska niissä voi olla eroja. Sanoit, että tietojen ero voi olla sellainen, että se ei tyydytä yritystäsi, etkä mene sinne ennen kuin se kopioidaan. Samanaikaisesti, jos et mennyt sinne pitkään aikaan ja aloit sitten menemään, tarvittavat tiedot eivät ole heti saatavilla. Eli jos menemme jatkuvasti isännän luo, siellä oleva välimuisti lämpenee, mutta kopiossa välimuisti viivästyy hieman.
Kyllä se on totta. Pcachessa ei ole haluamiasi tietolohkoja, todellisessa välimuistissa ei ole tietoa haluamistasi taulukoista, suunnitelmissa ei ole jäsennettyjä kyselyitä, ei ole mitään.
Ja kun sinulla on jonkinlainen klusteri ja lisäät sinne uuden replikan, niin sen käynnistyessä kaikki on huonosti, eli se lisää välimuistiaan.
Sain idean. Oikea tapa olisi suorittaa pieni prosenttiosuus kyselyistä ensin replikalla, mikä lämmittää välimuistia. Karkeasti sanottuna meillä on ehto, että meidän on oltava jäljessä mestarista enintään 10 sekuntia. Ja tämä ehto ei sisälly yhteen aaltoon, mutta joillekin asiakkaille sujuvasti.
Kyllä, lisää painoa.
Tämä on hyvä idea. Mutta ensin meidän on toteutettava tämä sulkeminen. Ensin meidän on sammutettava, ja sitten mietitään, miten kytketään päälle. Tämä on hieno ominaisuus, joka mahdollistaa sujuvan käytön.
Nginxillä on tämä vaihtoehto slowly start klusterissa palvelimelle. Ja hän lisää vähitellen kuormaa.
Kyllä, hieno idea, kokeilemme sitä, kun saamme sen valmiiksi.
Lähde: will.com