Savo kalboje Andrejus Borodinas jums pasakys, kaip jie atsižvelgė į PgBouncer mastelio keitimo patirtį kurdami ryšio telkinį. , kaip jie išleido jį gamyboje. Be to, aptarsime, kokias pulerio funkcijas norėtume matyti naujose versijose: mums svarbu ne tik patenkinti savo poreikius, bet ir plėtoti vartotojų bendruomenę .
Vaizdo įrašas:
Sveiki visi! Mano vardas Andrius.
„Yandex“ kuriu atvirojo kodo duomenų bazes. Ir šiandien turime temą apie ryšio telkinio jungtis.
Jei žinote, kaip paskambinti "connection pooler" rusiškai, pasakykite man. Labai noriu rasti gerą techninį terminą, kuris turėtų būti nustatytas techninėje literatūroje.
Tema yra gana sudėtinga, nes daugelyje duomenų bazių yra integruotas ryšio kaupiklis ir jums net nereikia apie tai žinoti. Kai kurie nustatymai, žinoma, yra visur, bet „Postgres“ tai neveikia. Lygiagrečiai (HighLoad++ 2019) yra Nikolajaus Samokhvalovo ataskaita apie užklausų nustatymą „Postgres“. Ir aš suprantu, kad čia atėjo žmonės, kurie jau puikiai sukonfigūravo užklausas, ir tai yra žmonės, kurie susiduria su retesnėmis sistemos problemomis, susijusiomis su tinklu, resursų panaudojimu. O kai kur tai gali būti gana sunku ta prasme, kad problemos nėra akivaizdžios.
„Yandex“ turi „Postgres“. Daugelis „Yandex“ paslaugų veikia „Yandex.Cloud“. Ir mes turime kelis petabaitus duomenų, kurie „Postgres“ generuoja mažiausiai milijoną užklausų per sekundę.
Ir visoms paslaugoms teikiame gana tipišką klasterį – tai yra pagrindinis pirminis mazgo mazgas, įprastos dvi kopijos (sinchroninė ir asinchroninė), atsarginė kopija, skaitymo užklausų mastelio keitimas kopijoje.
Kiekvienas klasterio mazgas yra „Postgres“, kuriame, be „Postgres“ ir stebėjimo sistemų, taip pat yra įdiegtas ryšio telkinys. Connection pooler naudojamas tvoroms ir pagal pagrindinę paskirtį.
Koks yra pagrindinis ryšio telkinio tikslas?
„Postgres“ naudoja darbo su duomenų baze proceso modelį. Tai reiškia, kad vienas ryšys yra vienas procesas, vienas Postgres backend. Ir šioje užpakalinėje programoje yra daug skirtingų talpyklų, kurias gana brangu padaryti skirtingą įvairiems ryšiams.
Be to, Postgres kode yra masyvas, vadinamas procArray. Jame yra pagrindiniai duomenys apie tinklo ryšius. Ir beveik visi procArray apdorojimo algoritmai yra linijinio sudėtingumo, jie veikia per visą tinklo jungčių masyvą. Tai gana greitas ciklas, tačiau su daugiau gaunamų tinklo jungčių viskas šiek tiek brangsta. O kai viskas šiek tiek pabrangsta, už daugybę tinklo jungčių mokate labai didelę kainą.
Galimi 3 būdai:
- Taikymo pusėje.
- Duomenų bazės pusėje.
- Ir tarp, tai yra, visų galimų derinių.
Deja, šiuo metu įmontuotas telkinys yra kuriamas. Dažniausiai tai daro „PostgreSQL Professional“ draugai. Kada jis pasirodys, sunku numatyti. Ir iš tikrųjų turime du sprendimus architekto pasirinkimui. Tai yra programos pusės baseinas ir tarpinis serveris.
Programos pusės baseinas yra lengviausias būdas. Ir beveik visos klientų tvarkyklės suteikia jums būdą: pavaizduoti milijonus savo ryšių kode kaip kelias dešimtis jungčių su duomenų baze.
Problema kyla dėl to, kad tam tikru momentu norite padidinti vidinės sistemos mastelį, norite ją įdiegti daugelyje virtualių mašinų.
Tada vis tiek supranti, kad turi dar kelias pasiekiamumo zonas, kelis duomenų centrus. O kliento pusės telkimo metodas lemia didelius skaičius. Didieji yra apie 10 000 jungčių. Tai kraštas, kuris gali gerai veikti.
Jei mes kalbame apie tarpinio serverio kaupiklius, yra du telkiniai, kurie gali padaryti daug dalykų. Jie yra ne tik telkėjai. Jie yra baseinai + daugiau šaunių funkcijų. Tai и .
Tačiau, deja, šios papildomos funkcijos reikia ne visiems. Ir tai veda prie to, kad kaupikliai palaiko tik seansų telkimą, t. y. vieną įeinantį klientą, vieną išeinantį klientą į duomenų bazę.
Tai nelabai tinka mūsų užduotims, todėl naudojame PgBouncer, kuris įgyvendina transakcijų telkimą, t.y. serverio ryšiai susiejami su kliento ryšiais tik operacijos metu.
Ir ant mūsų krūvio – tai tiesa. Tačiau yra keletas problemų.
Problemos prasideda, kai norite diagnozuoti seansą, nes visi įeinantys ryšiai yra vietiniai. Visi atėjo su „loopback“ ir kažkodėl tampa sunku atsekti seansą.
Žinoma, galite naudoti application_name_add_host. Tai yra Bouncer šalutinis būdas pridėti IP adresą prie programos_pavadinimo. Tačiau programos_pavadinimas nustatomas naudojant papildomą ryšį.
Šioje diagramoje geltona linija yra tikrosios užklausos, o mėlyna – užklausos, kurios patenka į duomenų bazę. Ir šis skirtumas yra būtent programos_pavadinimas nustatymas, kuris reikalingas tik sekimui, tačiau jis nėra nemokamas.
Be to, Bouncer negali apriboti vieno telkinio, t. y. duomenų bazės prisijungimų skaičiaus vienam vartotojui vienai duomenų bazei.
Prie ko tai veda? Turite įkeltą paslaugą, parašytą C ++, o kažkur netoliese yra nedidelė paslauga, kuri nedaro nieko blogo su baze, tačiau jos tvarkyklė išprotėja. Jis atidaro 20 000 jungčių, o visa kita lauks. Net jūsų kodas yra teisingas.
Žinoma, mes parašėme nedidelį Bouncer pataisą, kuris pridėjo šį nustatymą, t. y. apribojo klientų skaičių prie baseino.
Tai būtų galima padaryti Postgres pusėje, t.y. apriboti vaidmenis duomenų bazėje iki jungčių skaičiaus.
Bet tada jūs prarandate galimybę suprasti, kodėl neturite ryšių su serveriu. PgBouncer nerodo ryšio klaidos, visada grąžina tą pačią informaciją. Ir jūs negalite suprasti: galbūt jūsų slaptažodis pasikeitė, galbūt duomenų bazė tiesiog sumažėjo, galbūt kažkas negerai. Bet diagnozės nėra. Jei seanso nepavyksta nustatyti, nežinosite, kodėl to negalima padaryti.
Tam tikru momentu žiūrite į programos grafikus ir matote, kad programa neveikia.
Pažiūrėkite į viršų ir pamatysite, kad „Bouncer“ yra vienos gijos. Tai lūžis tarnybos gyvenime. Suprantate, kad per pusantrų metų ruošėtės padidinti duomenų bazės mastelį, ir jums reikia išplėsti telkinį.
Priėjome prie išvados, kad mums reikia daugiau PgBouncers.
Bouncer buvo šiek tiek pataisytas.
Ir jie padarė taip, kad pakartotinai naudojant TCP prievadą būtų galima iškelti keletą atšokėjų. Ir jau operacinė sistema automatiškai perduoda įeinančius TCP ryšius tarp jų ratu-robin'om.
Klientams tai yra aišku, t. y. atrodo, kad turite vieną „Bouncer“, bet neveikiantys ryšiai tarp veikiančių „Bouncers“ yra suskaidyti.
Ir tam tikru momentu galite pastebėti, kad šie 3 atšokėjai valgo savo pagrindą 100%. Jums reikia nemažai Bouncer. Kodėl?
Nes turite TLS. Turite užšifruotą ryšį. Ir jei palyginsite „Postgres“ su TLS ir be jo, pastebėsite, kad užmegztų ryšių skaičius sumažėja beveik dviem dydžiais, kai įjungtas šifravimas, nes TLS rankos paspaudimas eikvoja procesoriaus išteklius.
O viršuje galite pamatyti nemažai kriptografinių funkcijų, kurios vykdomos įeinančių ryšių bangos metu. Kadangi mūsų pagrindinė gali persijungti tarp pasiekiamumo zonų, gaunamų ryšių banga yra gana tipiška situacija. Tai yra, dėl tam tikrų priežasčių senasis pagrindinis buvo nepasiekiamas, visa apkrova buvo išsiųsta į kitą duomenų centrą. Jie visi vienu metu ateis pasisveikinti su TLS.
Ir daugybė TLS rankos paspaudimų gali jau ne pasveikinti Bouncerį, o suspausti jam gerklę. Įeinančių jungčių banga gali būti neslopinama dėl skirtojo laiko. Jei bandysite iš naujo į bazę be eksponentinio atsitraukimo, jie negrįš vėl ir vėl nuoseklia banga.
Štai 16 PgBouncer, kurie 16% įkelia 100 branduolių, pavyzdys.
Atvykome į kaskadinį PgBouncer. Tai geriausia konfigūracija, kurią galime pasiekti naudodami „Bouncer“ apkrovą. Mūsų išoriniai atmetėjai tarnauja TCP rankos paspaudimui, o vidiniai atmetėjai – tikram telkimui, kad nebūtų labai suskaidytos išorinės jungtys.
Šioje konfigūracijoje galimas minkštas paleidimas iš naujo. Galite iš naujo paleisti visus šiuos 18 „Bouncers“ po vieną. Tačiau išlaikyti tokią konfigūraciją yra gana sunku. Sistemos administratoriai, DevOps ir žmonės, kurie tikrai atsakingi už šį serverį, nebus labai patenkinti šia schema.
Atrodytų, kad visi mūsų patobulinimai gali būti reklamuojami atvirajame kode, tačiau „Bouncer“ nelabai palaiko. Pavyzdžiui, galimybė paleisti kelis PgBouncers tame pačiame prievade buvo suteikta prieš mėnesį. Ištraukimo užklausa su šia funkcija buvo pateikta prieš keletą metų.
Arba dar vienas pavyzdys. „Postgres“ galite atšaukti vykdomą užklausą išsiųsdami paslaptį kitam ryšiui be papildomo autentifikavimo. Tačiau kai kurie klientai tiesiog atsiunčia TCP atstatymą, ty nutraukia tinklo ryšį. Ką Bouncer su tuo darys? Jis nieko nepadarys. Jis ir toliau vykdys užklausą. Jei gavote daugybę jungčių, kurios padėjo pagrindą su nedidelėmis užklausomis, tada tiesiog atjungti ryšį nuo „Bouncer“ nepakaks, vis tiek turite užpildyti tas užklausas, kurios veikia duomenų bazėje.
Tai buvo pataisyta ir problema vis dar nėra sujungta su Bouncer's prieš srovę.
Taip ir priėjome išvados, kad mums reikia savo ryšio poolerio, kuris bus kuriamas, pataisytas, kuriame bus galima greitai sutvarkyti problemas ir kuris, žinoma, turi būti kelių gijų.
Kaip pagrindinę užduotį nustatome kelių gijų kūrimą. Turime gerai valdyti gaunamų TLS ryšių bangą.
Norėdami tai padaryti, turėjome sukurti atskirą biblioteką, pavadintą Machinarium, kuri skirta tinklo ryšio mašinų būsenoms apibūdinti kaip serijos kodą. Jei pažvelgsite į libpq šaltinio kodą, pamatysite gana sudėtingus skambučius, kurie gali grąžinti jums rezultatą ir pasakyti: „Paskambinkite šiek tiek vėliau. Šiuo metu aš turiu IO, bet kai IO praeina, aš apkraunu procesorių. Ir tai yra kelių lygių schema. Tinklo sąveiką paprastai apibūdina būsenos mašina. Daug taisyklių, tokių kaip „Jei anksčiau gavau N dydžio paketo antraštę, tai dabar laukiu N baitų“, „Jei išsiunčiau SYNC paketą, tai dabar laukiu paketo su rezultatų metaduomenimis“. Pasirodo, gana sudėtingas priešintuityvus kodas, tarsi labirintas būtų paverstas linijos nuskaitymu. Padarėme taip, kad vietoj būsenos mašinos programuotojas pagrindinį sąveikos kelią aprašo įprasto imperatyvaus kodo forma. Tiesiog šiame privalomame kode reikia įterpti vietas, kur reikia nutraukti vykdymo seką, laukiant duomenų iš tinklo, perduodant vykdymo kontekstą kitai korutinai (žalia gija). Šis metodas panašus į tai, kad iš eilės užrašome labiausiai laukiamą labirinto kelią, o tada pridedame prie jo šakas.
Dėl to turime vieną giją, kuri verčia TCP priimti, o TPC ryšį perduoda daugybei darbuotojų.
Tokiu atveju kiekvienas kliento ryšys visada veikia viename procesoriuje. Ir tai leidžia padaryti jį patogiu talpyklai.
Be to, mes šiek tiek patobulinome mažų paketų surinkimą į vieną didelį paketą, kad būtų galima iškrauti sistemos TCP steką.
Be to, patobulinome transakcijų telkimą ta prasme, kad sukonfigūruota „Odyssey“ gali siųsti CANCEL ir ROLLBACK, jei nutrūktų tinklo ryšys, t. y. jei niekas nelauks užklausos, „Odyssey“ nurodys duomenų bazei nebandyti įvykdyti prašymas, kuris gali eikvoti brangius išteklius.
Ir kai tik įmanoma, palaikome ryšius su tuo pačiu klientu. Taip išvengiama iš naujo įdiegti programos_pavadinimas_add_host. Jei įmanoma, mes neturime papildomo diagnostikos reikalingų parametrų atstatymo.
Mes dirbame „Yandex.Cloud“ interesais. Ir jei naudojate valdomą PostgreSQL ir turite įdiegtą ryšio kaupiklį, galite sukurti loginę replikaciją į išorę, t. y. palikite mus, jei norite, naudodami loginį replikavimą. Bouncer už loginės replikacijos srauto neduos.
Tai yra loginės replikacijos nustatymo pavyzdys.
Be to, mes palaikome fizinį replikavimą į išorę. Žinoma, debesyje tai neįmanoma, nes tada klasteris suteiks jums per daug informacijos apie save. Bet jūsų įrenginiuose, jei jums reikia fizinio replikavimo naudojant Odisėjos ryšio telkinį, tai įmanoma.
„Odyssey“ turi visiškai suderinamą stebėjimą su „PgBouncer“. Turime tą pačią konsolę, kuri vykdo beveik visas tas pačias komandas. Jei kažko trūksta, išsiųskite užklausą arba bent jau iškilo problema GitHub, mes atliksime reikiamas komandas. Bet mes jau turime pagrindines PgBouncer konsolės funkcijas.
Ir, žinoma, turime klaidų persiuntimą. Mes grąžinsime klaidą, apie kurią pranešė bazė. Gausite informaciją, kodėl tavęs nėra bazėje, o ne tik kad tavęs nėra.
Ši funkcija išjungta, jei jums reikia 100% suderinamumo su PgBouncer. Mes galime elgtis kaip Bouncer, bet kuriuo atveju.
Vystymasis
Keletas žodžių apie Odisėjos šaltinio kodą.
Pavyzdžiui, yra komandos „Pristabdyti / Tęsti“. Paprastai jie naudojami duomenų bazei atnaujinti. Jei jums reikia atnaujinti „Postgres“, galite jį pristabdyti ryšio telkinyje, atlikti pg_upgrade, tada tęsti. O iš kliento pusės atrodys, kad duomenų bazė tiesiog sulėtėjo. Šią funkciją mums suteikė bendruomenės žmonės. Ji dar nemirė, bet greitai viskas bus. (jau miręs)
- jau miręs
Be to, viena iš naujų PgBouncer funkcijų yra SCRAM Authentication palaikymas, kurį mums taip pat atnešė žmogus, nedirbantis Yandex.Cloud. Abi yra sudėtingos ir svarbios.
Todėl norėčiau papasakoti, iš ko padaryta Odisėja, jei ir jūs dabar norėtumėte parašyti kodą.
Turite originalią Odisėjos bazę, kuri remiasi dviem pagrindinėmis bibliotekomis. Kiwi biblioteka yra Postgres pranešimų protokolo įgyvendinimas. Tai yra, vietinis „Postgres“ proto 3 yra standartiniai pranešimai, kuriais gali keistis priekinės ir užpakalinės programos. Jie įgyvendinami Kiwi bibliotekoje.
„Machinarium“ biblioteka yra gijų diegimo biblioteka. Nedidelis šio Machinarium fragmentas parašytas assembler. Bet nesijaudinkite, yra tik 15 eilučių.
Odisėjos architektūra. Yra pagrindinė mašina, kuri vykdo korutines. Ši mašina priima įeinančius TCP ryšius ir paskirsto darbuotojus.
Vieno darbuotojo viduje gali dirbti kelių klientų tvarkytojas. Taip pat pagrindinėje gijoje sukasi konsolė ir crone užduočių apdorojimas, kad būtų pašalintos jungtys, kurių baseine nebereikia.
Odyssey testuojamas naudojant standartinį Postgres testų rinkinį. Tiesiog paleidžiame diegimo patikrinimą per Bouncer ir Odyssey, gauname nulinį div. Yra keletas testų, susijusių su datos formatavimu, kurie nepavyksta „Bouncer“ ir „Odyssey“.
Be to, yra daug vairuotojų, kurie turi savo testavimą. Ir mes naudojame jų testus, kad išbandytume Odisėją.
Be to, dėl mūsų pakopinės konfigūracijos turime išbandyti įvairius paketus: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, kad įsitikintume, jog jei Odyssey yra kurioje nors pakopinėje dalyje, jis taip pat veikia taip, kaip tikėtasi. .
Rake
Gamyboje naudojame Odisėją. Ir nebūtų teisinga, jei sakyčiau, kad viskas veikia. Ne, t. y. taip, bet ne visada. Pavyzdžiui, gamyboje viskas tiesiog veikė, tada atėjo draugai iš PostgreSQL Professional ir pasakė, kad mums nutekėjo atmintis. Jie tikrai buvo, mes juos sutvarkėme. Bet tai buvo paprasta.
Tada nustatėme, kad ryšio telkinys turi gaunamus TLS ryšius ir išeinančius TLS ryšius. O ryšiams reikia kliento sertifikatų ir serverio sertifikatų.
„Bouncer“ ir „Odyssey“ serverio sertifikatai perskaitomi naudojant „pccache“, tačiau klientų sertifikatų nereikia perskaityti iš „pcche“, nes mūsų keičiamo dydžio „Odyssey“ ilgainiui priklauso nuo šio sertifikato nuskaitymo sistemos veikimo. Tai mums buvo netikėta, nes jis ne iš karto pailsėjo. Iš pradžių ji didėjo tiesiškai, o po 20 000 vienu metu gaunamų jungčių ši problema pasireiškė.
Prijungiamas autentifikavimo metodas yra galimybė autentifikuoti naudojant įmontuotus lunux įrankius. PgBouncer programoje jis įgyvendintas taip, kad yra atskira gija, laukianti atsakymo iš PAM, ir yra pagrindinė PgBouncer gija, kuri aptarnauja esamą ryšį ir gali paprašyti jų gyventi PAM gijoje.
To neįgyvendinome dėl vienos paprastos priežasties. Turime daug srautų. Kodėl mums to reikia?
Dėl to gali kilti problemų, nes jei turite PAM autentifikavimą ir ne PAM autentifikavimą, didelė PAM autentifikavimo banga gali žymiai atidėti ne PAM autentifikavimą. Tai vienas iš tų dalykų, kurių nepataisėme. Bet jei norite tai pataisyti, galite tai padaryti.
Kitas grėblys buvo su tuo, kad turime vieną giją, kuri priima visus įeinančius ryšius. Tada jie perkeliami į darbuotojų grupę, kur vyks TLS rankos paspaudimas.
Dėl to, jei turite nuoseklią 20 000 tinklo jungčių bangą, jie visi bus priimti. O kliento pusėje libpq pradės pranešti apie skirtąjį laiką. Pagal numatytuosius nustatymus ten yra maždaug 3 sekundės.
Jei jie negali visi patekti į bazę vienu metu, tada jie negali patekti į bazę, nes visa tai gali būti padengta neeksponentiniu pakartotiniu bandymu.
Mes nukopijavome PgBouncer schemą čia, kad sumažintume priimtinų TCP jungčių skaičių.
Jei matome, kad priimame ryšius, bet jie neturi laiko paspausti rankų, dedame į eilę, kad jie nevartotų procesoriaus resursų. Tai lemia tai, kad tuo pačiu metu rankos paspaudimas gali būti atliktas ne visoms jungtims. Bet bent jau kažkas pateks į duomenų bazę, net jei apkrova pakankamai stipri.
Planas
Ką norėtumėte pamatyti ateityje Odisėjoje? Ką esame pasirengę vystyti patys ir ko tikimės iš bendruomenės?
2019 m. rugpjūčio mėn.
Štai kaip atrodė Odisėjos planas rugpjūčio mėnesį:
- Mes norėjome SCRAM ir PAM autentifikavimo.
- Norėjome persiųsti skaitymo užklausas į budėjimo režimą.
- Norėčiau paleisti iš naujo internete.
- Ir galimybė pristabdyti serveryje.
Pusė šio plano padaryta, o ne mes. Ir tai yra gerai. Taigi aptarkime, kas liko, ir pridėkime daugiau.
? Turime kopijas, kurios, neįvykdusios prašymų, tiesiog sušildys orą. Mums jų reikia, kad būtų užtikrintas perjungimas ir perjungimas. Iškilus problemoms viename iš duomenų centrų, norėčiau juos užimti naudingu darbu. Nes negalime kitaip konfigūruoti tų pačių centrinių procesorių, tos pačios atminties, nes kitaip replikacija neveiks.
Iš esmės Postgres, pradedant nuo 10, jungiantis galima nurodyti session_attrs. Galite išvardyti visus prisijungusius duomenų bazių pagrindinius kompiuterius ir pasakyti, kodėl einate į duomenų bazę: rašyti arba tik skaityti. Ir pats vairuotojas iš sąrašo išsirinks pirmą jam labiausiai patinkantį pagrindinį kompiuterį, kuris atitinka session_attrs reikalavimus.
Tačiau šio metodo problema yra ta, kad jis nekontroliuoja replikacijos delsos. Gali būti, kad turite kokią nors kopiją, kuriai nepriimtinas jūsų paslaugos laikas. Norėdami, kad kopijos skaitymo užklausos būtų vykdomos visapusiškai, Odisėjoje turime palaikyti galimybę neveikti, kai neįmanoma nuskaityti.
Odyssey retkarčiais turi eiti į duomenų bazę ir paklausti replikacijos atstumo nuo pirminės. Ir jei jis pasiekė ribą, neįleiskite naujų užklausų į duomenų bazę, pasakykite klientui, kad reikia iš naujo inicijuoti ryšius ir, galbūt, pasirinkti kitą pagrindinį kompiuterį užklausoms vykdyti. Tai leis duomenų bazei greitai atkurti replikacijos delsą ir vėl grįžti atsakyti su užklausa.
Įdiegimo datas įvardinti sunku, nes tai atvirojo kodo. Bet, tikiuosi, ne 2,5 metų, kaip kolegos iš PgBouncer. Būtent tokią funkciją norėčiau pamatyti Odisėjoje.
. Dabar paruoštą pareiškimą galite sukurti dviem būdais. Pirma, galite vykdyti SQL komandą, būtent „paruošta“. Norėdami suprasti šią SQL komandą, turime išmokti suprasti SQL iš Bouncer pusės. Tai būtų per daug, nes tai per daug, nes mums reikia viso analizatoriaus. Negalime išanalizuoti kiekvienos SQL komandos.
Tačiau proto3 yra parengtas pareiškimas pranešimo protokolo lygiu. Ir tai yra ta vieta, kai informacija, kad kuriamas parengtas pareiškimas, ateina struktūrizuota forma. Ir mes galėtume paremti supratimą, kad tam tikru serverio ryšiu klientas paprašė sukurti parengtus pareiškimus. Ir net jei sandoris yra uždarytas, vis tiek turime palaikyti ryšį tarp serverio ir kliento.
Bet čia yra dialogo neatitikimas, nes kažkas sako, kad reikia suprasti, kokius parengtus pareiškimus klientas sukūrė ir pasidalinti serverio ryšiu tarp visų klientų, kurie sukūrė šį serverio ryšį, t.y. kas sukūrė tokį parengtą pareiškimą.
Andresas Freundas sakė, kad jei pas jus atėjo klientas, kuris jau sukūrė tokį paruoštą pareiškimą kitame serverio ryšyje, sukurkite jį jam. Bet atrodo kiek neteisinga užklausas vykdyti duomenų bazėje, o ne kliente, bet kūrėjo, kuris rašo protokolą sąveikai su duomenų baze požiūriu, būtų patogu, jei jam būtų tiesiog suteiktas tinklo ryšys kad turi tokį parengtą prašymą.
Ir dar viena funkcija, kurią turime įdiegti. Dabar turime stebėjimą, suderinamą su PgBouncer. Galime grąžinti vidutinį užklausos vykdymo laiką. Tačiau vidutinis laikas yra vidutinė temperatūra ligoninėje: kam šalta, kam šilta – vidutiniškai visi sveiki. Tai netiesa.
Turime įdiegti procentilių palaikymą, kuris rodytų, kad yra lėtų užklausų, kurios eikvoja išteklius ir padarytų stebėjimą priimtinesnį.
Svarbiausia, kad noriu 1.0 versijos (1.1 versija jau išleista). Faktas yra tas, kad dabar „Odyssey“ yra 1.0rc versijoje, t. y. kandidato išleisti. Ir visas mano išvardintas grėblys buvo sutvarkytas lygiai ta pačia versija, išskyrus atminties nutekėjimą.
Ką mums reikš 1.0 versija? Mes iškeliame Odisėją į savo bazes. Ji jau veikia mūsų duomenų bazėse, bet kai pasiekia 1 000 000 užklausų per sekundę tašką, galime pasakyti, kad tai yra išleidimo versija ir tai versija, kurią galima pavadinti 1.0.
Keletas bendruomenės žmonių paprašė daugiau pristabdymo ir SCRAM 1.0 versijoje. Tačiau tai reikš, kad turėsime išleisti kitą versiją į gamybinę versiją, nes nei SCRAM, nei pauzė dar nebuvo sujungti. Tačiau greičiausiai ši problema bus išspręsta gana greitai.
Laukiu jūsų užklausos. Taip pat norėčiau išgirsti, kokių problemų turite su Bouncer. Aptarkime juos. Galbūt galime įgyvendinti kai kurias jums reikalingas funkcijas.
Tuo mano dalis baigta. Norėčiau išgirsti jūsų nuomonę. Ačiū!
Klausimai
Jei įdėsiu savo aplikacijos_pavadinimą, ar jis bus teisingai išmestas, įskaitant operacijų telkimą Odisėjoje?
Odisėja ar Bouncer?
Odisėjoje. Bouncer mestas.
Padarysime rinkinį.
Ir jei mano tikrasis ryšys peršoks per kitus ryšius, ar jis bus perduotas?
Mes sudarysime visų išvardytų parametrų rinkinį. Negaliu pasakyti, ar programos_pavadinimas yra šiame sąraše. Atrodo, kad jis jį ten matė. Mes nustatysime visus tuos pačius parametrus. Su vienu prašymu rinkinys padarys viską, ką klientas įdiegė paleidimo metu.
Ačiū Andrejui už pranešimą! Geras reportažas! Džiaugiuosi, kad „Odisėja“ kas minutę vystosi vis greičiau. Norėčiau tęsti tą patį. Jau prašėme turėti kelių duomenų šaltinių ryšį, kad „Odyssey“ galėtų prisijungti prie skirtingų duomenų bazių tuo pačiu metu, t. y. pagrindinio pagrindinio, ir automatiškai prisijungti prie naujojo pagrindinio po perkėlimo.
Taip, aš, regis, prisimenu tą diskusiją. Dabar yra kelios saugyklos. Tačiau tarp jų nėra perjungimo. Iš mūsų pusės turime paklausti serverio, ar jis vis dar gyvas, ir suprasti, kad įvyko pertrūkis, kuris iškvies pg_recovery. Turiu standartinį būdą suprasti, kad mes neatėjome pas meistrą. Ir mes turime kažkaip suprasti iš klaidų ar kaip? Tai yra, idėja įdomi, apie ją diskutuojama. Rašyk daugiau komentarų. Jei turite dirbančias rankas, kurios moka C, tai paprastai yra nuostabu.
Mus domina ir kopijų mastelio keitimo problema, nes norime, kad programų kūrėjams būtų kuo paprastesnis replikuotų grupių priėmimas. Bet čia norėčiau daugiau komentarų, tai yra, kaip tai padaryti, kaip tai padaryti gerai.
Klausimas taip pat yra apie kopijas. Pasirodo, jūs turite meistrą ir keletą kopijų. Ir aišku, kad jie rečiau eina į repliką nei pas meistrą dėl jungčių, nes gali skirtis. Sakėte, kad duomenų skirtumas gali būti toks, kad jūsų verslas netenkins ir neisite, kol jis nebus atkartotas. Tuo pačiu metu, jei ilgą laiką ten nebuvote, o tada pradėjote eiti, jums reikalingi duomenys nebus iškart pasiekiami. Tai yra, jei nuolat einame pas pagrindinį kompiuterį, tada talpykla ten įkaista, o talpykla šiek tiek atsilieka nuo replikos.
Taip, tai tiesa. Pcache nebus duomenų blokų, kurių norite, realioje talpykloje nebus informacijos apie norimas lenteles, planuose nebus analizuotų užklausų, visiškai nieko.
O kai turi kažkokią klasterį ir pridedi ten naują repliką, tai kol ji paleidžiama, jame viskas yra blogai, t.y. išauga talpykla.
Supratau. Teisingas būdas būtų pirmiausia paleisti nedidelę užklausų dalį kopijoje, kuri sušildytų talpyklą. Grubiai tariant, turime sąlygą, kad turime atsilikti nuo meistro ne daugiau nei 10 sekundžių. Ir ši sąlyga turėtų būti įtraukta ne į vieną bangą, o sklandžiai kai kuriems klientams.
Taip, padidinti svorį.
Tai gera idėja. Bet pirmiausia turite įgyvendinti šį išjungimą. Pirmiausia reikia išjungti, o tada galvosime, kaip įjungti. Tai puiki funkcija sklandžiai įjungti.
nginx turi šią parinktį slowly start serverio klasteryje. Ir jis palaipsniui kaupia krūvį.
Taip, puiki idėja. Kai tik pasieksime, pabandysime.
Šaltinis: www.habr.com