Í skýrslu sinni mun Andrey Borodin segja þér hvernig þeir tóku mið af upplifuninni af því að skala PgBouncer þegar hann hannaði tengilaugarann. , þegar þeir rúlluðu því út í framleiðslu. Að auki munum við ræða hvaða aðgerðir togarans við viljum sjá í nýjum útgáfum: það er mikilvægt fyrir okkur ekki aðeins að mæta þörfum okkar heldur að þróa notendasamfélagið .
Video:
Hæ allir! Ég heiti Andrew.
Hjá Yandex þróa ég opna gagnagrunna. Og í dag erum við með umræðuefni um tengingar við tengingar.
Ef þú veist hvernig á að hringja í Connection Pooler á rússnesku, segðu mér þá. Mig langar virkilega að finna gott tæknihugtak sem ætti að festa í sessi í tæknibókmenntum.
Viðfangsefnið er frekar flókið, vegna þess að í mörgum gagnagrunnum er tengilaugarinn innbyggður og þú þarft ekki einu sinni að vita um það. Auðvitað eru nokkrar stillingar alls staðar, en í Postgres virkar það ekki þannig. Og samhliða (á HighLoad++ 2019) er skýrsla eftir Nikolai Samokhvalov um uppsetningu fyrirspurna í Postgres. Og eins og ég skil það kom hingað fólk sem var þegar búið að stilla fyrirspurnir sínar fullkomlega, og þetta er fólk sem stendur frammi fyrir sjaldgæfari kerfisvandamálum sem tengjast netkerfinu og nýtingu auðlinda. Og sums staðar gæti það verið ansi erfitt í þeim skilningi að vandamálin eru ekki augljós.
Yandex er með Postgres. Margar Yandex þjónustur búa í Yandex.Cloud. Og við höfum nokkur petabæta af gögnum sem búa til að minnsta kosti milljón beiðnir á sekúndu í Postgres.
Og við bjóðum upp á nokkuð staðlaðan þyrping fyrir alla þjónustu - þetta er aðal aðalhnútur hnútsins, venjulegar tvær eftirmyndir (samstilltur og ósamstilltur), öryggisafrit, mælikvarði lestrarbeiðna á eftirmyndinni.
Hver klasahnútur er Postgres, þar sem auk Postgres og vöktunarkerfa er einnig settur upp tengipooler. Connection pooler er notaður til girðinga og í megintilgangi þess.
Hver er megintilgangur tengingalaugar?
Postgres tekur upp ferlilíkan þegar unnið er með gagnagrunn. Þetta þýðir að ein tenging er eitt ferli, einn Postgres bakendi. Og í þessum bakenda eru fullt af mismunandi skyndiminni, sem er frekar dýrt að búa til mismunandi fyrir mismunandi tengingar.
Að auki hefur Postgres kóða fylki sem kallast procArray. Það inniheldur grunngögn um nettengingar. Og næstum öll procArray vinnslu reiknirit hafa línulega margbreytileika; þau keyra yfir allt úrval nettenginga. Þetta er frekar fljótlegt hringrás, en með fleiri komandi nettengingum verða hlutirnir aðeins dýrari. Og þegar hlutirnir verða aðeins dýrari geturðu endað með því að borga mjög hátt verð fyrir margar nettengingar.
Það eru 3 mögulegar aðferðir:
- Á umsóknarhliðinni.
- Á gagnagrunnsmegin.
- Og á milli, það er alls kyns samsetningar.
Því miður er innbyggði pooler í þróun. Vinir okkar hjá PostgreSQL Professional gera þetta aðallega. Hvenær það birtist er erfitt að spá fyrir um. Og í raun höfum við tvær lausnir fyrir arkitektinn að velja úr. Þetta eru laug forritahliðar og proxy laug.
Laug við notkunarhlið er auðveldasta leiðin. Og næstum allir ökumenn viðskiptavina veita þér leið: kynntu milljónir tenginga þinna í kóða sem nokkra tugi tenginga við gagnagrunninn.
Vandamálið sem kemur upp er að á ákveðnum tímapunkti viltu stækka bakendann, þú vilt dreifa honum á margar sýndarvélar.
Þá áttarðu þig á því að þú ert með nokkur fleiri tiltæk svæði, nokkur gagnaver. Og sameiningaraðferðin við viðskiptavininn leiðir til mikils fjölda. Stórir eru um 10 tengingar. Þetta er brúnin sem getur virkað venjulega.
Ef við tölum um proxy poolers, þá eru tveir poolers sem geta gert ýmislegt. Þeir eru ekki bara púllarar. Þeir eru poolers + meiri flott virkni. Þetta и .
En því miður þurfa ekki allir þessa viðbótarvirkni. Og það leiðir til þess að laugarar styðja aðeins setusamskipti, þ.
Þetta er ekki mjög hentugur fyrir okkar tilgangi, svo við notum PgBouncer, sem útfærir viðskiptasamsöfnun, þ.e.a.s. miðlaratengingar eru aðeins pössuð við tengingar viðskiptavinar á meðan viðskiptin standa yfir.
Og í vinnuálagi okkar er þetta satt. En það eru nokkur vandamál.
Vandamálin byrja þegar þú vilt greina lotu, vegna þess að allar komandi tengingar þínar eru staðbundnar. Allir komu með loopback og einhvern veginn verður erfitt að rekja fundinn.
Auðvitað geturðu notað application_name_add_host. Þetta er leið á Bouncer hliðinni til að bæta IP tölu við application_name. En application_name er stillt af viðbótartengingu.
Á þessu grafi, þar sem gula línan er raunverulegar beiðnir, og þar sem bláa línan eru beiðnir sem fljúga inn í gagnagrunninn. Og þessi munur er einmitt uppsetningin á application_name, sem er aðeins þörf til að rekja, en það er alls ekki ókeypis.
Að auki, í Bouncer er ekki hægt að takmarka eina laug, þ.e. fjölda gagnagrunnstenginga á tiltekinn notanda, á tiltekinn gagnagrunn.
Til hvers leiðir þetta? Þú ert með hlaðna þjónustu sem er skrifuð í C++ og einhvers staðar nálægt litla þjónustu á hnút sem gerir ekkert hræðilegt við gagnagrunninn, en bílstjórinn hans klikkar. Það opnar 20 tengingar og allt annað mun bíða. Jafnvel kóðinn þinn er eðlilegur.
Við skrifuðum auðvitað lítinn plástur fyrir Bouncer sem bætti þessari stillingu við, þ.e.a.s. takmarkaði viðskiptavini við sundlaugina.
Það væri hægt að gera þetta á Postgres hliðinni, þ.e.a.s. takmarka hlutverkin í gagnagrunninum með fjölda tenginga.
En þá missirðu hæfileikann til að skilja hvers vegna þú hefur engar tengingar við netþjóninn. PgBouncer kastar ekki tengingarvillu, það skilar alltaf sömu upplýsingum. Og þú getur ekki skilið: kannski hefur lykilorðið þitt breyst, kannski týndist gagnagrunnurinn bara, kannski er eitthvað að. En það er engin greining. Ef ekki er hægt að stofna fund, muntu ekki vita hvers vegna ekki er hægt að stofna hana.
Á ákveðnum tímapunkti horfirðu á forritagrafin og sér að forritið virkar ekki.
Horfðu efst og sjáðu að Bouncer er einn-þráður. Þetta eru tímamót í lífi þjónustunnar. Þú áttar þig á því að þú varst að undirbúa að stækka gagnagrunninn eftir eitt og hálft ár og þú þarft að stækka poolerinn.
Við höfum komist að þeirri niðurstöðu að við þurfum fleiri PgBouncers.
Bouncer hefur verið lagfærður aðeins.
Og þeir gerðu það þannig að hægt væri að hækka nokkra skoppara með því að endurnýta TCP tengið. Og stýrikerfið flytur sjálfkrafa komandi TCP tengingar á milli þeirra með því að nota round-robin.
Þetta er gagnsætt fyrir viðskiptavini, sem þýðir að það lítur út fyrir að þú sért með einn Bouncer, en þú ert með sundurliðun á aðgerðalausum tengingum á milli keyrandi Bouncers.
Og á ákveðnu augnabliki gætirðu tekið eftir því að þessir 3 Bouncers éta hver kjarnann sinn um 100%. Þú þarft töluvert marga Bouncers. Hvers vegna?
Vegna þess að þú ert með TLS. Þú ert með dulkóðaða tengingu. Og ef þú mælir Postgres með og án TLS, muntu komast að því að fjöldi staðfestra tenginga lækkar um næstum tvær stærðargráður með dulkóðun virka, vegna þess að TLS handabandið eyðir CPU auðlindum.
Og efst geturðu séð töluvert af dulmálsaðgerðum sem eru framkvæmdar þegar bylgja komandi tenginga er. Þar sem aðal okkar getur skipt á milli framboðssvæða er bylgja komandi tenginga nokkuð dæmigert ástand. Það er að segja að af einhverjum ástæðum var gamla forvalið ekki tiltækt, allt álagið var sent í annað gagnaver. Þeir munu allir koma til að heilsa TLS á sama tíma.
Og mikill fjöldi TLS handabands gæti ekki lengur sagt halló við Bouncer, heldur kreistir hann hálsinn. Vegna tímaleysis getur bylgja komandi tenginga orðið ódempuð. Ef þú reynir aftur að grunninum án veldisvísis bakslags, munu þeir ekki koma aftur og aftur í samfelldri bylgju.
Hér er dæmi um 16 PgBouncers sem hlaða 16 kjarna á 100%.
Við komum að Cascade PgBouncer. Þetta er besta stillingin sem hægt er að ná á álagi okkar með Bouncer. Ytri bouncers okkar eru notaðir fyrir TCP handaband og innri bouncers eru notaðir til raunverulegrar sameiningar, til að sundra ytri tengingum ekki of mikið.
Í þessari uppsetningu er möguleg endurræsing möguleg. Þú getur endurræst alla þessa 18 Bouncers einn í einu. En það er frekar erfitt að viðhalda slíkri uppsetningu. Sysadmins, DevOps, og fólk sem er í raun ábyrgt fyrir þessum þjóni mun ekki vera mjög ánægður með þetta fyrirkomulag.
Það virðist sem hægt sé að færa allar endurbætur okkar yfir í opinn hugbúnað, en Bouncer er ekki mjög vel studdur. Til dæmis var hæfileikinn til að keyra nokkra PgBouncers á einni höfn framinn fyrir mánuði síðan. Það var dragbeiðni með þessum eiginleika fyrir nokkrum árum síðan.
Eða enn eitt dæmið. Í Postgres geturðu hætt við beiðni í vinnslu með því að senda leyndarmálið í aðra tengingu án óþarfa auðkenningar. En sumir viðskiptavinir senda einfaldlega TCP endurstillingu, þ.e.a.s. þeir rjúfa nettenginguna. Hvað mun Bouncer gera? Hann mun ekki gera neitt. Það mun halda áfram að framkvæma beiðnina. Ef þú hefur fengið gríðarlegan fjölda tenginga sem hafa búið til gagnagrunn með litlum beiðnum, þá er ekki nóg að aftengja tenginguna frá Bouncer, þú þarft líka að klára þær beiðnir sem eru í gangi í gagnagrunninum.
Þetta hefur verið lagfært og þetta vandamál hefur ekki enn verið sameinað í andstreymis Bouncer.
Og þannig komumst við að þeirri niðurstöðu að við þurfum okkar eigin tengingapottara, sem verður þróaður, lagfærður, þar sem hægt er að laga vandamál fljótt og sem auðvitað verður að vera margþráður.
Við setjum fjölþráð sem aðalverkefni. Við þurfum að geta tekist á við bylgjuna af komandi TLS tengingum vel.
Til að gera þetta þurftum við að þróa sérstakt bókasafn sem heitir Machinarium, sem er hannað til að lýsa vélarástandi nettengingar sem raðnúmer. Ef þú skoðar libpq frumkóðann sérðu nokkuð flókin símtöl sem geta skilað þér niðurstöðu og sagt: „Hringdu í mig seinna. Eins og er er ég með IO í bili, en þegar IO hverfur mun ég hafa álag á örgjörvann. Og þetta er fjölþrepa kerfi. Netsamskiptum er venjulega lýst af ríkisvél. Fullt af reglum eins og „Ef ég fékk áður pakkahaus af stærð N, nú bíð ég eftir N bætum,“ „Ef ég sendi SYNC pakka, bíð ég nú eftir pakka með niðurstöðulýsigögnum. Niðurstaðan er frekar erfiður, gagnsæi kóði, eins og völundarhúsinu væri breytt í línuskönnun. Við gerðum það þannig að í stað ríkisvélar lýsir forritarinn aðalleið samskipta í formi venjulegs nauðsynlegs kóða. Það er bara þannig að í þessum brýna kóða þarftu að setja inn staði þar sem þarf að rjúfa framkvæmdarröðina með því að bíða eftir gögnum frá netinu, senda framkvæmdarsamhengið yfir í annan kóróútínu (grænn þráð). Þessi nálgun er svipuð þeirri staðreynd að við skrifum niður mest væntanlegu leiðina í völundarhúsinu í röð og bætum síðan greinum við það.
Fyrir vikið höfum við einn þráð sem gerir TCP samþykki og round-robin sendir TPC tenginguna til margra starfsmanna.
Í þessu tilviki keyrir hver biðlaratenging alltaf á einum örgjörva. Og þetta gerir þér kleift að gera það skyndiminnisvænt.
Og að auki höfum við bætt lítillega söfnun lítilla pakka í einn stóran pakka til að létta á TCP-stafla kerfisins.
Að auki höfum við bætt viðskiptasamsöfnun í þeim skilningi að Odyssey, þegar hann er stilltur, getur sent CANCEL og ROLLBACK ef bilun verður í nettengingu, þ.e. ef enginn bíður eftir beiðni mun Odyssey segja gagnagrunninum að reyna ekki að uppfylla beiðnina sem gæti sóað dýrmætum auðlindum.
Og þegar mögulegt er höldum við tengingum við sama viðskiptavin. Þetta kemur í veg fyrir að þurfa að setja upp application_name_add_host aftur. Ef þetta er mögulegt, þá þurfum við ekki að endurstilla færibreyturnar sem þarf til greiningar.
Við vinnum í þágu Yandex.Cloud. Og ef þú notar stýrða PostgreSQL og ert með uppsettan tengingarútbúnað geturðu búið til rökræna afritun út á við, þ.e.a.s. látið okkur, ef þú vilt, nota rökræna afritun. Bouncer mun ekki gefa út rökrétt afritunarflæði utan.
Þetta er dæmi um að setja upp rökræna afritun.
Að auki höfum við stuðning við líkamlega afritun út á við. Í skýinu er þetta auðvitað ómögulegt, því þá mun þyrpingin gefa þér of miklar upplýsingar um sjálfan sig. En í uppsetningum þínum, ef þú þarft líkamlega afritun í gegnum tengingargeymirinn í Odyssey, þá er þetta mögulegt.
Odyssey hefur fullkomlega samhæft eftirlit með PgBouncer. Við erum með sömu stjórnborðið sem keyrir næstum allar sömu skipanirnar. Ef eitthvað vantar, sendu þá dragbeiðni, eða að minnsta kosti vandamál á GitHub, og við munum klára nauðsynlegar skipanir. En við höfum nú þegar helstu virkni PgBouncer stjórnborðsins.
Og auðvitað erum við með villuframsendingu. Við munum skila villunni sem gagnagrunnurinn greinir frá. Þú færð upplýsingar um hvers vegna þú ert ekki með í gagnagrunninum, en ekki bara að þú sért ekki með í honum.
Þessi eiginleiki er óvirkur ef þú þarft 100% eindrægni við PgBouncer. Við getum hagað okkur á sama hátt og Bouncer, bara til öryggis.
Þróun
Nokkur orð um Odyssey frumkóðann.
Til dæmis eru „Hlé / halda áfram“ skipanir. Þeir eru venjulega notaðir til að uppfæra gagnagrunninn. Ef þú þarft að uppfæra Postgres, þá geturðu gert hlé á því í tengingarpottinum, gert pg_upgrade og síðan haldið áfram. Og frá hlið viðskiptavinarins mun það líta út eins og gagnagrunnurinn hafi einfaldlega verið að hægja á sér. Þessi virkni kom til okkar af fólki úr samfélaginu. Hún er ekki frosin ennþá, en bráðum verður allt. (Nú þegar frosinn)
- þegar frosinn
Að auki er einn af nýju eiginleikunum í PgBouncer stuðningur við SCRAM Authentication, sem einnig kom til okkar af einstaklingi sem vinnur ekki í Yandex.Cloud. Bæði eru flókin virkni og mikilvæg.
Þess vegna langar mig að segja þér úr hverju Odyssey er gert, ef þú vilt líka skrifa smá kóða núna.
Þú ert með Odyssey upprunagrunninn, sem byggir á tveimur aðalsöfnum. Kiwi bókasafnið er útfærsla á Postgres skilaboðasamskiptareglunum. Það er að segja, innfædd frumefni 3 af Postgres eru venjuleg skilaboð sem framenda og bakenda geta skiptst á. Þau eru útfærð í Kiwi bókasafninu.
Machinarium bókasafnið er þráðarútfærslusafn. Lítið brot af þessu Machinarium er skrifað á samsetningarmáli. En ekki hafa áhyggjur, það eru bara 15 línur.
Odyssey arkitektúr. Það er aðalvél sem coroutines eru í gangi á. Þessi vél útfærir að taka við komandi TCP tengingum og dreifa þeim meðal starfsmanna.
Umsjónarmaður fyrir nokkra viðskiptavini getur unnið innan eins starfsmanns. Aðalþráðurinn keyrir einnig stjórnborðið og vinnslu crone-verkefna til að eyða tengingum sem ekki er lengur þörf á í sundlauginni.
Odyssey er prófað með venjulegu Postgres prófunarsvítunni. Við keyrum bara install-check í gegnum Bouncer og í gegnum Odyssey, við fáum núll div. Það eru nokkur próf sem tengjast dagsetningarsniði sem standast ekki nákvæmlega það sama í Bouncer og í Odyssey.
Að auki eru margir ökumenn sem hafa sín eigin próf. Og við notum prófin þeirra til að prófa Odyssey.
Þar að auki, vegna fossauppsetningar okkar, verðum við að prófa ýmsa búnta: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey til að vera viss um að ef Odyssey endaði í einhverjum hlutum í fossinum virkar það líka enn eins og við er að búast.
Hrífa
Við notum Odyssey í framleiðslu. Og það væri ekki sanngjarnt ef ég segði að allt virki bara. Nei, það er, já, en ekki alltaf. Til dæmis, í framleiðslu virkaði bara allt, svo komu vinir okkar frá PostgreSQL Professional og sögðu að við værum með minnisleka. Þeir voru það í raun, við leiðréttum þá. En það var einfalt.
Þá komumst við að því að tengingargeymirinn er með innkomnar TLS tengingar og útleiðar TLS tengingar. Og tengingar krefjast viðskiptavinavottorðs og netþjónsvottorðs.
Bouncer og Odyssey netþjónaskírteini eru endurlesin af pcache þeirra, en viðskiptavinavottorð þarf ekki að endurlesa frá pcache, vegna þess að stigstærð Odyssey okkar keyrir á endanum inn í kerfisframmistöðu við að lesa þetta skírteini. Þetta kom okkur á óvart því það tók hann ekki langan tíma að standast. Í fyrstu stækkaði það línulega, en eftir 20 komandi samtímis tengingar kom þetta vandamál fram.
Pluggable Authentication Method er hæfileikinn til að sannvotta með innbyggðum Lunux verkfærum. Í PgBouncer er það útfært á þann hátt að það er sérstakur þráður til að bíða eftir svari frá PAM og það er aðal PgBouncer þráður sem þjónustar núverandi tengingu og getur beðið þá um að búa í PAM þræðinum.
Við útfærðum þetta ekki af einni einfaldri ástæðu. Við erum með marga þræði. Af hverju þurfum við þetta?
Þetta getur að lokum skapað vandamál að því leyti að ef þú ert með PAM auðkenningu og ekki-PAM auðkenningu, þá getur mikil bylgja af PAM auðkenningu tafið verulega án PAM auðkenningar. Þetta er eitt af því sem við höfum ekki lagað. En ef þú vilt laga það geturðu gert þetta.
Önnur hrífa var að við erum með einn þráð sem tekur við öllum komandi tengingum. Og svo eru þeir fluttir í starfsmannalaugina, þar sem TLS handabandið fer fram.
Niðurstaðan, ef þú ert með samhangandi bylgju af 20 nettengingum, verða þær allar samþykktar. Og á biðlarahlið mun libpq byrja að tilkynna um tímamörk. Sjálfgefið virðist það vera 000 sekúndur.
Ef þeir geta ekki allir farið inn í gagnagrunninn á sama tíma, þá geta þeir ekki farið inn í gagnagrunninn, vegna þess að allt þetta er hægt að ná yfir með tilraunum án veldisvísis.
Við komumst að þeirri niðurstöðu að við afrituðum áætlunina frá PgBouncer hér með þeirri staðreynd að við erum með að takmarka fjölda TCP tenginga sem við samþykkjum.
Ef við sjáum að við erum að samþykkja tengingar, en þeir hafa á endanum ekki tíma til að handtaka, setjum við þá í biðröð þannig að þeir sóa ekki CPU auðlindum. Þetta leiðir til þess að ekki er víst að samtímis handabandi sé framkvæmt fyrir allar tengingar sem hafa borist. En allavega mun einhver fara inn í gagnagrunninn, jafnvel þótt álagið sé frekar mikið.
vegamaður
Hvað myndir þú vilja sjá í framtíðinni í Odyssey? Hvað erum við tilbúin til að þróa sjálf og hvers væntum við af samfélaginu?
Frá og með ágúst 2019.
Svona leit Odyssey vegakortið út í ágúst:
- Við vildum SCRAM og PAM auðkenningu.
- Við vildum framsenda lestrarbeiðnir í biðstöðu.
- Mig langar í endurræsingu á netinu.
- Og getu til að gera hlé á þjóninum.
Helmingur þessarar vegaáætlunar er lokið og ekki af okkur. Og þetta er gott. Svo skulum við ræða það sem eftir er og bæta við meira.
? Við erum með eftirlíkingar sem munu einfaldlega hita loftið án þess að framkvæma beiðnir. Við þurfum þá til að veita bilun og skipta. Ef upp koma vandamál í einni af gagnaverunum, langar mig að taka þau upp með gagnlegri vinnu. Vegna þess að við getum ekki stillt sömu miðlægu örgjörvana, sama minni á annan hátt, því annars virkar afritun ekki.
Í grundvallaratriðum, í Postgres, frá og með 10, er hægt að tilgreina session_attrs þegar tengst er. Þú getur skráð alla gagnagrunnshýsilinn í tengingunni og sagt hvers vegna þú ert að fara í gagnagrunninn: skrifa eða lesa eingöngu. Og ökumaðurinn sjálfur mun velja fyrsta gestgjafann á listanum sem honum líkar best, sem uppfyllir kröfur session_attrs.
En vandamálið við þessa nálgun er að hún stjórnar ekki afritunartöfinni. Þú gætir átt einhverja eftirmynd sem hefur dregist á eftir í óviðunandi tíma fyrir þjónustu þína. Til þess að virkja fullkomna framkvæmd lesfyrirspurna á eftirmynd, þurfum við í meginatriðum að styðja getu Odyssey til að keyra ekki þegar ekki er hægt að lesa hana.
Odyssey verður að fara í gagnagrunninn af og til og biðja um afritunarfjarlægð frá aðal. Og ef það hefur náð viðmiðunarmörkum, ekki leyfa nýjar beiðnir inn í gagnagrunninn, segja viðskiptavininum að hann þurfi að hefja tengingar aftur og mögulega velja annan hýsil til að framkvæma beiðnir. Þetta gerir gagnagrunninum kleift að endurheimta afritunartöfina fljótt og snúa aftur til að svara með beiðni.
Það er erfitt að gefa tímaramma fyrir innleiðingu vegna þess að það er opinn uppspretta. En ég vona, ekki 2,5 ár eins og kollegar mínir frá PgBouncer. Þetta er þátturinn sem ég myndi vilja sjá í Odyssey.
. Nú er hægt að búa til tilbúna yfirlýsingu á tvo vegu. Í fyrsta lagi geturðu framkvæmt SQL skipunina, nefnilega "tilbúinn". Til að skilja þessa SQL skipun þurfum við að læra að skilja SQL á Bouncer hliðinni. Þetta væri of mikið, því það er of mikið, þar sem við þurfum allan þáttarann. Við getum ekki flokkað hverja SQL skipun.
En það er tilbúin yfirlýsing á stigi skilaboðasamskiptareglna á proto3. Og þetta er staðurinn þegar upplýsingarnar um að verið sé að búa til yfirlýsingu koma í skipulögðu formi. Og við gætum stutt þann skilning að á einhverri netþjónstengingu bað viðskiptavinurinn um að búa til undirbúnar yfirlýsingar. Og jafnvel þótt viðskiptin séu lokuð þurfum við samt að viðhalda tengingu milli netþjónsins og viðskiptavinarins.
En hér kemur upp misræmi í samræðunni, vegna þess að einhver segir að þú þurfir að skilja hvers konar tilbúnar staðhæfingar viðskiptavinurinn bjó til og deila netþjónstengingunni á milli allra viðskiptavina sem bjuggu til þessa netþjónstengingu, þ.e.a.s.
Andres Freund sagði að ef viðskiptavinur kemur til þín sem hefur þegar búið til slíka tilbúna yfirlýsingu í annarri netþjónstengingu, búðu þá til hana fyrir hann. En það virðist svolítið rangt að framkvæma fyrirspurnir í gagnagrunninum í stað viðskiptavinarins, en frá sjónarhóli þróunaraðilans sem skrifar samskiptareglur fyrir samskipti við gagnagrunninn, þá væri þægilegt ef hann fengi einfaldlega nettengingu þar sem það er svona tilbúin fyrirspurn.
Og enn einn eiginleiki sem við þurfum að innleiða. Við höfum nú eftirlit sem er samhæft við PgBouncer. Við getum skilað meðalframkvæmdartíma fyrirspurna. En meðaltíminn er meðalhiti á sjúkrahúsinu: sumir eru kaldir, aðrir eru hlýir - að meðaltali eru allir heilir. Það er ekki satt.
Við þurfum að innleiða stuðning við hundraðshlutahópa, sem myndi gefa til kynna að það séu hægar fyrirspurnir sem sóa auðlindum og myndi gera eftirlit ásættanlegra.
Það mikilvægasta er að ég vil útgáfu 1.0 (útgáfa 1.1 er þegar komin út). Staðreyndin er sú að Odyssey er nú í útgáfu 1.0rc, þ.e. útgáfuframbjóðandi. Og öll vandamálin sem ég taldi upp voru laguð með nákvæmlega sömu útgáfunni, fyrir utan minnisleka.
Hvað mun útgáfa 1.0 þýða fyrir okkur? Við erum að rúlla út Odyssey til bækistöðva okkar. Það er nú þegar í gangi á gagnagrunnum okkar, en þegar það nær 1 beiðnum á sekúndu, þá getum við sagt að þetta sé útgáfuútgáfan og þetta er útgáfa sem má kalla 000.
Nokkrir í samfélaginu hafa beðið um að útgáfa 1.0 innihaldi hlé og SCRAM. En þetta mun þýða að við þurfum að setja næstu útgáfu í framleiðslu, því hvorki SCRAM né hlé hefur enn verið drepið. En líklega verður þetta mál leyst nokkuð fljótt.
Ég bíð eftir dráttarbeiðni þinni. Mig langar líka að heyra hvaða vandamál þú átt við Bouncer. Við skulum ræða þau. Kannski getum við útfært nokkrar aðgerðir sem þú þarft.
Þetta er lok míns þáttar, mig langar að hlusta á þig. Þakka þér fyrir!
spurningar
Ef ég stilli mitt eigið application_name, verður það framsent á réttan hátt, þar á meðal í færslusamsetningu í Odyssey?
Odyssey eða Bouncer?
Í Odyssey. Í Bouncer er því hent.
Við gerum sett.
Og ef raunveruleg tenging mín hoppar á aðrar tengingar, verður hún send?
Við munum búa til safn af öllum breytum sem eru skráðar á listanum. Ég get ekki sagt hvort application_name er á þessum lista. Ég held ég hafi séð hann þarna. Við munum setja allar sömu breytur. Með einni beiðni mun settið gera allt sem var sett upp af viðskiptavininum við ræsingu.
Þakka þér, Andrey, fyrir skýrsluna! Góð skýrsla! Ég er ánægður með að Odyssey þróast hraðar og hraðar á hverri mínútu. Ég vil halda svona áfram. Við höfum þegar beðið þig um að hafa tengingu með mörgum gagnaveitum þannig að Odyssey geti tengst mismunandi gagnagrunnum samtímis, þ.e.a.s. masterslave, og síðan sjálfkrafa tengst nýjum skipstjóra eftir bilun.
Já, ég virðist muna eftir þessari umræðu. Nú eru nokkrar geymslur. En það er ekkert skipt á milli þeirra. Af okkar hálfu verðum við að kanna netþjóninn að hann sé enn á lífi og skilja að bilun hefur átt sér stað, sem mun kalla pg_recovery. Ég hef staðlaðan skilning á því að við komum ekki til meistarans. Og eigum við einhvern veginn að skilja af mistökunum eða hvað? Það er að segja að hugmyndin er áhugaverð, það er verið að ræða hana. Skrifaðu fleiri athugasemdir. Ef þú ert með starfsmenn sem þekkja C, þá er það frábært.
Málið um stærðarstærð yfir eftirlíkingar vekur einnig áhuga fyrir okkur, vegna þess að við viljum gera upptöku endurtekinna klasa eins einfalda og mögulegt er fyrir forritara. En hér langar mig í fleiri athugasemdir, þ.e.a.s. nákvæmlega hvernig á að gera það, hvernig á að gera það vel.
Spurningin er líka um eftirlíkingar. Það kemur í ljós að þú ert með meistara og nokkrar eftirmyndir. Og það er greinilegt að þeir fara sjaldnar á eftirmyndina en til meistarans til að fá tengingar, vegna þess að þeir geta verið mismunandi. Þú sagðir að munurinn á gögnunum gæti verið slíkur að það myndi ekki fullnægja fyrirtæki þínu og þú munt ekki fara þangað fyrr en það er endurtekið. Á sama tíma, ef þú fórst ekki þangað í langan tíma og byrjaðir síðan að fara, þá verða gögnin sem þarf ekki strax tiltæk. Það er að segja, ef við förum stöðugt til meistarans, þá er skyndiminni þar hitað upp, en í eftirmyndinni seinkar skyndiminni aðeins.
Já það er satt. PCache mun ekki hafa gagnablokkirnar sem þú vilt, raunverulegt skyndiminni mun ekki hafa upplýsingar um töflurnar sem þú vilt, áætlanirnar munu ekki hafa þáttaðar fyrirspurnir, það verður alls ekkert.
Og þegar þú ert með einhvers konar klasa, og þú bætir við nýrri eftirmynd þar, þá á meðan hann byrjar, þá er allt slæmt í honum, þ.e.a.s. það eykur skyndiminni.
Ég fékk hugmyndina. Rétta aðferðin væri að keyra lítið hlutfall af fyrirspurnum á eftirmyndina fyrst, sem myndi hita upp skyndiminni. Í grófum dráttum höfum við það skilyrði að við verðum að vera ekki meira en 10 sekúndur á eftir meistaranum. Og þetta ástand er ekki innifalið í einni bylgju, heldur vel fyrir suma viðskiptavini.
Já, auka þyngd.
Þetta er góð hugmynd. En fyrst þurfum við að innleiða þessa lokun. Fyrst þurfum við að slökkva á og síðan hugsum við um hvernig á að kveikja. Þetta er frábær eiginleiki til að virkja vel.
Nginx hefur þennan möguleika slowly start í klasa fyrir netþjóninn. Og hann eykur álagið smám saman.
Já, frábær hugmynd, við reynum það þegar við komumst að.
Heimild: www.habr.com