Yn ei sgwrs, bydd Andrey Borodin yn dweud wrthych sut y gwnaethant ystyried profiad graddio PgBouncer wrth ddylunio cronfa cysylltiad , sut y maent yn ei gyflwyno yn cynhyrchu. Yn ogystal, byddwn yn trafod pa swyddogaethau o'r pŵlwr yr hoffem eu gweld mewn fersiynau newydd: mae'n bwysig inni nid yn unig ymdrin â'n hanghenion, ond datblygu'r gymuned ddefnyddwyr .
Fideo:
Helo pawb! Fy enw i yw Andrew.
Yn Yandex, rwy'n datblygu cronfeydd data ffynhonnell agored. A heddiw mae gennym bwnc am gysylltiadau pyllau cysylltiad.
Os ydych chi'n gwybod sut i alw pwll cysylltiad yn Rwsieg, yna dywedwch wrthyf. Rwyf wir eisiau dod o hyd i derm technegol da y dylid ei sefydlu yn y llenyddiaeth dechnegol.
Mae'r pwnc yn eithaf cymhleth, oherwydd mewn llawer o gronfeydd data mae'r cronfa ddata wedi'i ymgorffori ac nid oes angen i chi hyd yn oed wybod amdano. Mae rhai lleoliadau, wrth gwrs, ym mhobman, ond yn Postgres nid yw hyn yn gweithio. Ac ochr yn ochr (yn HighLoad ++ 2019) mae adroddiad gan Nikolai Samokhvalov ar sefydlu ymholiadau yn Postgres. Ac rwy'n deall bod pobl wedi dod yma sydd eisoes wedi ffurfweddu ceisiadau'n berffaith, a dyma bobl sy'n wynebu problemau system prinnach sy'n gysylltiedig â'r rhwydwaith, defnyddio adnoddau. Ac mewn rhai mannau gall fod yn eithaf anodd yn yr ystyr nad yw'r problemau'n amlwg.
Mae gan Yandex Postgres. Mae llawer o wasanaethau Yandex yn byw yn Yandex.Cloud. Ac mae gennym ni sawl petabytes o ddata sy'n cynhyrchu o leiaf miliwn o geisiadau yr eiliad yn Postgres.
Ac rydym yn darparu clwstwr eithaf nodweddiadol ar gyfer yr holl wasanaethau - dyma brif nod sylfaenol y nod, y ddau atgynhyrchiad arferol (cydamserol ac asyncronig), wrth gefn, graddio ceisiadau darllen ar y replica.
Postgres yw pob nod clwstwr, ac yn ogystal â Postgres a systemau monitro, gosodir cronfa cysylltu hefyd. Defnyddir pwll cysylltu ar gyfer ffensio ac at ei brif bwrpas.
Beth yw prif ddiben cronni cysylltiad?
Mae Postgres yn mabwysiadu model proses ar gyfer gweithio gyda chronfa ddata. Mae hyn yn golygu bod un cysylltiad yn un broses, un ôl-ôl Postgres. Ac mae yna lawer o wahanol caches yn y backend hwn, sy'n eithaf drud i'w gwneud yn wahanol ar gyfer gwahanol gysylltiadau.
Hefyd, mae amrywiaeth yn y cod Postgres o'r enw procArray. Mae'n cynnwys data sylfaenol am gysylltiadau rhwydwaith. Ac mae gan bron pob algorithm prosesu procArray gymhlethdod llinol, maen nhw'n rhedeg trwy'r amrywiaeth gyfan o gysylltiadau rhwydwaith. Mae'n gylchred eithaf cyflym, ond gyda mwy o gysylltiadau rhwydwaith yn dod i mewn, mae pethau'n mynd ychydig yn ddrytach. A phan fydd pethau'n mynd ychydig yn ddrytach, rydych chi'n talu pris uchel iawn am nifer fawr o gysylltiadau rhwydwaith.
Mae 3 dull posibl:
- Ar ochr y cais.
- Ar ochr y gronfa ddata.
- A rhwng, hynny yw, pob cyfuniad posibl.
Yn anffodus, mae'r pwllwr adeiledig yn cael ei ddatblygu ar hyn o bryd. Mae ffrindiau yn PostgreSQL Professional yn gwneud hyn yn bennaf. Mae'n anodd rhagweld pryd y bydd yn ymddangos. Ac mewn gwirionedd, mae gennym ddau ateb ar gyfer dewis pensaer. Y rhain yw pwll ochr cais a phwll dirprwy.
Pwll ochr cais yw'r ffordd hawsaf. Ac mae bron pob gyrrwr cleient yn rhoi ffordd i chi: i gynrychioli miliynau o'ch cysylltiadau yn y cod fel rhai dwsinau o gysylltiadau â'r gronfa ddata.
Mae yna broblem gyda'r ffaith eich bod chi am raddio'r backend ar adeg benodol, rydych chi am ei ddefnyddio i lawer o beiriannau rhithwir.
Yna rydych chi'n dal i sylweddoli bod gennych chi lawer mwy o barthau argaeledd, sawl canolfan ddata. Ac mae'r dull cronni ochr cleientiaid yn arwain at niferoedd mawr. Mae rhai mawr tua 10 o gysylltiadau. Mae hwn yn ymyl a all weithio'n iawn.
Os byddwn yn siarad am gronwyr dirprwyol, yna mae dau bwllwr a all wneud llawer o bethau. Nid pwllwyr yn unig ydyn nhw. Maen nhw'n bwllwyr + ymarferoldeb mwy cŵl. hwn и .
Ond, yn anffodus, nid yw pawb angen y swyddogaeth ychwanegol hon. Ac mae’n arwain at y ffaith bod pŵlwyr yn cefnogi cronni sesiynau yn unig, h.y. un cleient sy’n dod i mewn, un cleient sy’n mynd allan i’r gronfa ddata.
Nid yw hyn yn addas iawn ar gyfer ein tasgau, felly rydym yn defnyddio PgBouncer, sy'n gweithredu cronni trafodion, h.y. mae cysylltiadau gweinydd yn cael eu mapio i gysylltiadau cleient yn unig am gyfnod y trafodiad.
Ac ar ein llwyth - mae'n wir. Ond mae yna nifer o broblemau.
Mae problemau'n dechrau pan fyddwch chi eisiau gwneud diagnosis o sesiwn, oherwydd mae'r holl gysylltiadau sy'n dod i mewn yn lleol. Daeth pawb gyda loopback a rhywsut mae'n dod yn anodd olrhain y sesiwn.
Wrth gwrs gallwch chi ddefnyddio application_name_add_host. Dyma'r ochr Bouncer i ychwanegu cyfeiriad IP i'r application_name. Ond mae application_name wedi'i osod gan gysylltiad ychwanegol.
Ar y siart hwn, lle mae'r llinell felen yn geisiadau go iawn, a lle mae'r llinell las yn geisiadau sy'n hedfan i mewn i'r gronfa ddata. A'r gwahaniaeth hwn yn union yw gosodiad application_name, sydd ei angen ar gyfer olrhain yn unig, ond nid yw'n rhad ac am ddim o gwbl.
Yn ogystal, ni all Bouncer gyfyngu ar un gronfa, h.y. nifer y cysylltiadau cronfa ddata fesul defnyddiwr, fesul cronfa ddata.
Beth mae hyn yn arwain ato? Mae gennych wasanaeth wedi'i lwytho wedi'i ysgrifennu yn C ++ a rhywle gerllaw gwasanaeth bach ar nod nad yw'n gwneud dim o'i le ar y sylfaen, ond mae ei yrrwr yn mynd yn wallgof. Mae'n agor 20 o gysylltiadau a bydd popeth arall yn aros. Mae hyd yn oed eich cod yn gywir.
Wrth gwrs, fe wnaethon ni ysgrifennu darn bach ar gyfer Bouncer a ychwanegodd y gosodiad hwn, h.y. cyfyngu cleientiaid i'r pwll.
Byddai’n bosibl gwneud hyn ar ochr Postgres, h.y. cyfyngu’r rolau yn y gronfa ddata i nifer y cysylltiadau.
Ond yna rydych chi'n colli'r gallu i ddeall pam nad oes gennych chi unrhyw gysylltiadau â'r gweinydd. Nid yw PgBouncer yn taflu gwall cysylltiad, mae bob amser yn dychwelyd yr un wybodaeth. Ac ni allwch ddeall: efallai bod eich cyfrinair wedi newid, efallai bod y gronfa ddata wedi gostwng, efallai bod rhywbeth o'i le. Ond nid oes diagnosis. Os na ellir sefydlu'r sesiwn, ni fyddwch yn gwybod pam na ellir ei wneud.
Ar bwynt penodol, rydych chi'n edrych ar graffiau'r cais ac yn gweld nad yw'r cais yn gweithio.
Edrychwch ar y brig a gweld bod Bouncer yn un edau. Mae hwn yn drobwynt ym mywyd y gwasanaeth. Rydych chi'n deall eich bod chi'n paratoi i raddfa'r gronfa ddata mewn blwyddyn a hanner, ac mae angen i chi raddio'r pŵl.
Rydym wedi dod i'r casgliad bod angen mwy o PgBouncers arnom.
Mae bownsar wedi'i glytio ychydig.
Ac fe wnaethon nhw ei gwneud hi fel y gellir codi nifer o Bownswyr gydag ailddefnyddio'r porthladd TCP. Ac eisoes mae'r system weithredu yn trosglwyddo cysylltiadau TCP sy'n dod i mewn rhyngddynt yn awtomatig trwy rownd-robin'om.
Mae hyn yn dryloyw i gleientiaid, h.y. mae'n edrych fel bod gennych chi un Bouncer, ond mae gennych chi ddarniad o gysylltiadau segur rhwng rhedeg Bouncers.
Ac ar ryw adeg, efallai y byddwch yn sylwi bod y 3 Bownsiwr hyn yn bwyta eu craidd gan 100%. Mae angen tipyn o bownsar arnoch chi. Pam?
Oherwydd bod gennych TLS. Mae gennych gysylltiad wedi'i amgryptio. Ac os ydych chi'n meincnodi Postgres gyda a heb TLS, fe welwch fod nifer y cysylltiadau sefydledig yn gostwng bron i ddau orchymyn maint gydag amgryptio wedi'i alluogi, oherwydd bod ysgwyd llaw TLS yn defnyddio adnoddau CPU.
Ac yn y brig, gallwch weld cryn dipyn o swyddogaethau cryptograffig sy'n cael eu gweithredu yn ystod ton o gysylltiadau sy'n dod i mewn. Gan y gall ein cynradd newid rhwng parthau argaeledd, mae ton o gysylltiadau sy'n dod i mewn yn sefyllfa eithaf nodweddiadol. Hynny yw, am ryw reswm, nid oedd yr hen ysgol gynradd ar gael, anfonwyd y llwyth cyfan i ganolfan ddata arall. Byddan nhw i gyd yn dod i ddweud helo wrth TLS ar yr un pryd.
Ac efallai na fydd nifer fawr o ysgwyd llaw TLS yn cyfarch Bouncer yn barod, ond yn gwasgu ei wddf. Mae'n bosibl y bydd ton o gysylltiadau sy'n dod i mewn yn dod yn ddigyfnewid oherwydd y terfyn amser. Os ydych chi'n ceisio dychwelyd i'r gwaelod heb esbonyddol wrth gefn, ni fyddant yn dod yn ôl drosodd a throsodd mewn ton gydlynol.
Dyma enghraifft o 16 PgBouncers sy'n llwytho 16 craidd ar 100%.
Rydym wedi cyrraedd y PgBouncer rhaeadru. Dyma'r cyfluniad gorau y gallwn ei gyflawni ar ein llwyth Bouncer. Mae ein Bownsars allanol yn gwasanaethu ar gyfer ysgwyd llaw TCP, ac mae Bownswyr mewnol yn gwasanaethu ar gyfer cronni go iawn, er mwyn peidio â darnio cysylltiadau allanol yn fawr.
Yn y cyfluniad hwn, mae ailgychwyn meddal yn bosibl. Gallwch ailgychwyn yr holl 18 Bownsiwr hyn fesul un. Ond mae cynnal cyfluniad o'r fath yn eithaf anodd. Ni fydd gweinyddwyr systemau, DevOps, na'r bobl sy'n wirioneddol gyfrifol am y gweinydd hwn yn hapus iawn â'r cynllun hwn.
Mae'n ymddangos y gellir hyrwyddo ein holl welliannau mewn ffynhonnell agored, ond nid yw Bouncer yn cefnogi'n dda iawn. Er enghraifft, ymrwymwyd y gallu i redeg PgBouncers lluosog ar yr un porthladd fis yn ôl. Roedd cais tynnu gyda'r nodwedd hon ychydig flynyddoedd yn ôl.
Neu un enghraifft arall. Yn Postgres, gallwch ganslo cais rhedeg trwy anfon y gyfrinach i gysylltiad arall heb y dilysiad ychwanegol. Ond mae rhai cleientiaid yn syml yn anfon ailosodiad TCP, h.y. maent yn torri'r cysylltiad rhwydwaith. Beth fydd Bouncer yn ei wneud gyda hyn? Ni fydd yn gwneud dim. Bydd yn parhau i weithredu'r cais. Os ydych chi wedi derbyn nifer fawr o gysylltiadau sydd wedi gosod y sylfaen gyda cheisiadau bach, yna ni fydd datgysylltu'r cysylltiad o Bouncer yn ddigon, mae angen i chi gwblhau'r ceisiadau hynny sy'n rhedeg yn y gronfa ddata o hyd.
Mae hyn wedi'i glytio ac nid yw'r mater wedi'i gyfuno o hyd â Bouncer i fyny'r afon.
Ac felly daethom i'r casgliad bod angen ein cronfa gyswllt ein hunain, a fydd yn cael ei ddatblygu, ei glytiog, lle bydd yn bosibl datrys problemau'n gyflym ac y mae'n rhaid iddo, wrth gwrs, fod yn aml-edau.
Rydym yn gosod multithreading fel y brif dasg. Mae angen i ni allu trin y don o gysylltiadau TLS sy'n dod i mewn yn dda.
I wneud hyn, bu'n rhaid i ni ddatblygu llyfrgell ar wahân o'r enw Machinarium, sydd wedi'i chynllunio i ddisgrifio cyflwr peiriant cysylltiad rhwydwaith fel cod cyfresol. Os edrychwch ar god ffynhonnell libpq, fe welwch alwadau eithaf cymhleth a all ddychwelyd canlyniad i chi a dweud, “Ffoniwch fi ychydig yn ddiweddarach. Ar hyn o bryd mae gen i IO am y tro, ond pan fydd yr IO yn pasio, mae gen i lwyth ar y prosesydd. Ac mae hwn yn gynllun aml-lefel. Disgrifir rhyngweithio rhwydwaith fel arfer gan beiriant cyflwr. Mae llawer o reolau fel "Pe bawn i'n derbyn pennawd pecyn o faint N yn flaenorol, yna nawr rydw i'n aros am N bytes", "Pe bawn i'n anfon pecyn SYNC, yna nawr rydw i'n aros am becyn gyda metadata canlyniad." Mae'n troi allan yn god gwrth-sythweledol braidd yn anodd, fel pe bai'r ddrysfa wedi'i throsi'n sgan llinell. Fe'i gwnaethom fel bod y rhaglennydd yn disgrifio'r prif lwybr rhyngweithio ar ffurf cod rheidiol arferol yn lle peiriant cyflwr. Dim ond yn y cod hanfodol hwn, mae angen i chi fewnosod lleoedd lle mae angen ymyrryd â'r dilyniant gweithredu trwy aros am ddata o'r rhwydwaith, gan drosglwyddo'r cyd-destun gweithredu i goroutine arall (edau gwyrdd). Mae'r dull hwn yn debyg i'r ffaith ein bod yn ysgrifennu'r llwybr mwyaf disgwyliedig yn y ddrysfa yn olynol, ac yna'n ychwanegu canghennau ato.
O ganlyniad, mae gennym un edefyn sy'n gwneud derbyniad TCP ac mae robin crwn yn trosglwyddo cysylltiad TPC i lawer o weithwyr.
Yn yr achos hwn, mae pob cysylltiad cleient bob amser yn rhedeg ar un prosesydd. Ac mae hyn yn caniatáu ichi ei wneud yn gyfeillgar i storfa.
Ac ar wahân, rydym wedi gwella ychydig ar y casgliad o becynnau bach yn un pecyn mawr er mwyn dadlwytho pentwr TCP y system.
Yn ogystal, rydym wedi gwella cronni trafodion yn yr ystyr y gall Odyssey, o'i ffurfweddu, anfon CANSLO a ROLL back rhag ofn y bydd cysylltiad rhwydwaith yn methu, h.y. os nad oes unrhyw un yn aros am y cais, bydd Odyssey yn dweud wrth y gronfa ddata i beidio â cheisio cyflawni. y cais a all wastraffu adnoddau gwerthfawr.
A phryd bynnag y bo modd, rydym yn cadw cysylltiadau â'r un cleient. Mae hyn yn osgoi gorfod ailosod application_name_add_host. Os yn bosibl, yna nid oes gennym ailosodiad ychwanegol o'r paramedrau sydd eu hangen ar gyfer diagnosteg.
Rydym yn gweithio er budd Yandex.Cloud. Ac os ydych chi'n defnyddio PostgreSQL a reolir a bod gennych bwlliwr cysylltiad wedi'i osod, gallwch greu atgynhyrchu rhesymegol tuag allan, h.y. ein gadael ni os dymunwch, gan ddefnyddio atgynhyrchu rhesymegol. Ni fydd bownsar y tu allan i'r llif o atgynhyrchu rhesymegol yn rhoi.
Dyma enghraifft o sefydlu atgynhyrchu rhesymegol.
Yn ogystal, mae gennym gefnogaeth ar gyfer atgynhyrchu corfforol tuag allan. Yn y Cwmwl, wrth gwrs, mae'n amhosibl, oherwydd yna bydd y clwstwr yn rhoi gormod o wybodaeth i chi amdano'i hun. Ond yn eich gosodiadau, os oes angen atgynhyrchu corfforol arnoch trwy bwlliwr cysylltiad yn Odyssey, mae'n bosibl.
Mae gan Odyssey fonitro cwbl gydnaws â PgBouncer. Mae gennym yr un consol sy'n gweithredu bron pob un o'r un gorchmynion. Os oes rhywbeth ar goll, anfonwch gais tynnu, neu o leiaf mater ar GitHub, byddwn yn cwblhau'r gorchmynion angenrheidiol. Ond mae gennym eisoes brif ymarferoldeb y consol PgBouncer.
Ac wrth gwrs mae gennym ni gamgymeriadau wrth anfon ymlaen. Byddwn yn dychwelyd y gwall a adroddwyd gan y sylfaen. Byddwch yn cael gwybodaeth pam nad ydych yn y ganolfan, nid dim ond nad ydych ynddo.
Mae'r nodwedd hon wedi'i hanalluogi rhag ofn y bydd angen 100% o gydnawsedd â PgBouncer. Gallwn ymddwyn fel Bouncer, rhag ofn.
Datblygiad
Ychydig eiriau am god ffynhonnell Odyssey.
Er enghraifft, mae yna orchmynion "Saib / Ailddechrau". Fe'u defnyddir fel arfer i ddiweddaru'r gronfa ddata. Os oes angen i chi uwchraddio Postgres, gallwch ei seibio yn y cronwr cysylltiad, gwneud pg_upgrade, yna ailddechrau. Ac o ochr y cleient, bydd yn edrych fel bod y gronfa ddata yn arafu. Daeth y swyddogaeth hon i ni gan bobl o'r gymuned. Nid yw hi wedi marw eto, ond yn fuan bydd popeth. (yn barod wedi marw)
- eisoes wedi marw
Yn ogystal, un o'r nodweddion newydd yn PgBouncer yw cefnogaeth Dilysu SCRAM, a ddygwyd atom hefyd gan berson nad yw'n gweithio yn Yandex.Cloud. Mae'r ddau yn ymarferoldeb cymhleth ac yn bwysig.
Felly, hoffwn ddweud wrthych o beth y gwneir Odyssey, rhag ofn eich bod hefyd am ysgrifennu rhywfaint o god yn awr.
Mae gennych sylfaen wreiddiol yr Odyssey, sy'n dibynnu ar ddwy brif lyfrgell. Mae llyfrgell Kiwi yn weithrediad o brotocol neges Postgres. Hynny yw, mae proto 3 brodorol Postgres yn negeseuon safonol y gall blaen ac ôl-wynebau eu cyfnewid. Fe'u gweithredir yn llyfrgell Kiwi.
Mae llyfrgell Machinarium yn llyfrgell gweithredu edafedd. Mae darn bach o'r Machinarium hwn wedi'i ysgrifennu mewn cyfosodwr. Ond peidiwch â phoeni, dim ond 15 llinell sydd.
pensaernïaeth Odyssey. Mae prif beiriant yn rhedeg coroutines. Mae'r peiriant hwn yn gweithredu derbyn cysylltiadau TCP sy'n dod i mewn a dosbarthu ymhlith gweithwyr.
O fewn un gweithiwr, gall triniwr sawl cleient weithio. A hefyd yn y prif edefyn, mae'r consol a phrosesu tasgau crone i gael gwared ar gysylltiadau nad oes eu hangen mwyach yn y pwll yn troelli.
Mae Odyssey yn cael ei brofi gan ddefnyddio cyfres brawf safonol Postgres. Rydyn ni'n rhedeg install-check trwy Bouncer a thrwy Odyssey, rydyn ni'n cael div null. Mae yna nifer o brofion yn ymwneud â fformatio dyddiad sy'n methu yn union yr un peth yn Bouncer ac Odyssey.
Yn ogystal, mae yna lawer o yrwyr sydd â'u profion eu hunain. Ac rydym yn defnyddio eu profion i brofi Odyssey.
Hefyd, oherwydd ein cyfluniad rhaeadru, mae'n rhaid i ni brofi bwndeli amrywiol: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey er mwyn bod yn siŵr, os yw Odyssey yn unrhyw un o'r rhannau yn y rhaeadru, mae hefyd yn dal i weithio yn ôl y disgwyl. .
Rake
Rydym yn defnyddio Odyssey wrth gynhyrchu. Ac ni fyddai'n deg pe bawn i'n dweud bod popeth yn gweithio. Na, h.y. ie, ond nid bob amser. Er enghraifft, wrth gynhyrchu roedd popeth newydd weithio, yna daeth ein ffrindiau o PostgreSQL Professional a dweud bod gennym ni ollyngiad cof. Roedden nhw wir, fe wnaethon ni eu trwsio. Ond roedd yn syml.
Yna canfuom fod gan y cronwr cysylltiad gysylltiadau TLS sy'n dod i mewn a chysylltiadau TLS sy'n mynd allan. Ac mae angen tystysgrifau cleient a thystysgrifau gweinydd ar gysylltiadau.
Mae tystysgrifau gweinydd Bouncer ac Odyssey yn cael eu hail-ddarllen gan pcache, ond nid oes angen ail-ddarllen tystysgrifau cleientiaid o pcache, oherwydd yn y pen draw mae ein Odyssey graddadwy yn dibynnu ar berfformiad y system o ddarllen y dystysgrif hon. Daeth hyn yn syndod i ni, oherwydd ni orphwysodd ar unwaith. Ar y dechrau, graddiodd yn llinol, ac ar ôl 20 o gysylltiadau cydamserol sy'n dod i mewn, daeth y broblem hon i'r amlwg.
Dull Dilysu Pluggable yw'r gallu i ddilysu gydag offer lunux adeiledig. Yn PgBouncer, fe'i gweithredir yn y fath fodd fel bod edau ar wahân yn aros am ymateb gan PAM ac mae yna brif edau PgBouncer sy'n gwasanaethu'r cysylltiad presennol a gall ofyn iddynt fyw yn yr edefyn PAM.
Ni wnaethom weithredu hyn am un rheswm syml. Mae gennym lawer o ffrydiau. Pam mae ei angen arnom?
O ganlyniad, gall hyn greu problemau yn yr ystyr, os oes gennych ddilysiad PAM a dilysiad nad yw'n PAM, yna gall ton fawr o ddilysu PAM ohirio dilysu nad yw'n PAM yn sylweddol. Mae'n un o'r pethau hynny nad ydym wedi'i drwsio. Ond os ydych chi am ei drwsio, gallwch chi wneud hyn.
Roedd cribin arall gyda'r ffaith bod gennym un edefyn sy'n derbyn yr holl gysylltiadau sy'n dod i mewn. Ac yna cânt eu trosglwyddo i'r pwll gweithwyr, lle bydd ysgwyd llaw TLS yn digwydd.
O ganlyniad, os oes gennych don gydlynol o 20 o gysylltiadau rhwydwaith, byddant i gyd yn cael eu derbyn. Ac ar ochr y cleient, bydd libpq yn dechrau adrodd am gyfnodau hir. Yn ddiofyn, mae fel 000 eiliad yno.
Os na allant i gyd fynd i mewn i'r sylfaen ar yr un pryd, yna ni allant fynd i mewn i'r sylfaen, oherwydd gall hyn i gyd gael ei gwmpasu gan ailgynnig anesbonyddol.
Yn y diwedd fe wnaethom gopïo'r cynllun PgBouncer yma fel ein bod wedi gwthio nifer y cysylltiadau TCP rydym yn eu derbyn.
Os gwelwn ein bod yn derbyn cysylltiadau, ond nad oes ganddynt amser i ysgwyd llaw yn y diwedd, rydym yn eu rhoi mewn ciw fel nad ydynt yn defnyddio adnoddau CPU. Mae hyn yn arwain at y ffaith efallai na fydd ysgwyd llaw ar yr un pryd yn cael ei berfformio ar gyfer pob cysylltiad sydd wedi cyrraedd. Ond o leiaf bydd rhywun yn mynd i mewn i'r gronfa ddata, hyd yn oed os yw'r llwyth yn ddigon cryf.
Map Ffyrdd
Beth hoffech chi ei weld yn yr Odyssey yn y dyfodol? Beth ydyn ni'n barod i'n datblygu ein hunain a beth ydyn ni'n ei ddisgwyl gan y gymuned?
Ar gyfer Awst 2019.
Dyma sut olwg oedd ar fap ffordd yr Odyssey ym mis Awst:
- Roeddem am gael dilysiad SCRAM a PAM.
- Roeddem am anfon ceisiadau darllen ymlaen i'r 'standby'.
- Hoffwn i-ailgychwyn ar-lein.
- A'r gallu i oedi ar y gweinydd.
Mae hanner y map ffordd hwn yn cael ei wneud, ac nid gennym ni. Ac mae hyn yn dda. Felly gadewch i ni drafod beth sydd ar ôl ac ychwanegu mwy.
? Mae gennym atgynyrchiadau a fydd, heb gyflawni ceisiadau, yn gwresogi'r aer yn unig. Mae angen iddynt ddarparu methiant i ddigidol a'r newid i ddigidol. Yn achos problemau yn un o'r canolfannau data, hoffwn eu meddiannu gyda rhywfaint o waith defnyddiol. Oherwydd na allwn ffurfweddu'r un proseswyr canolog, yr un cof mewn ffordd wahanol, oherwydd ni fydd atgynhyrchu yn gweithio fel arall.
Mewn egwyddor, yn Postgres, gan ddechrau o 10, mae'n bosibl nodi session_attrs wrth gysylltu. Gallwch restru'r holl westeion cronfa ddata yn y cysylltiad a dweud pam rydych chi'n mynd i'r gronfa ddata: ysgrifennu neu ddarllen yn unig. A bydd y gyrrwr ei hun yn dewis y gwesteiwr cyntaf ar y rhestr y mae'n ei hoffi orau, sy'n bodloni gofynion session_attrs.
Ond y broblem gyda'r dull hwn yw nad yw'n rheoli'r oedi wrth ddyblygu. Efallai bod gennych ryw fath o atgynhyrchiad sydd ar ei hôl hi gan amser annerbyniol ar gyfer eich gwasanaeth. Er mwyn gwneud defnydd llawn sylw o geisiadau darllen ar replica, mewn gwirionedd, mae angen inni gefnogi yn Odyssey y gallu i beidio â gweithio pan fydd yn amhosibl darllen.
Mae'n rhaid i Odyssey fynd i'r gronfa ddata o bryd i'w gilydd a gofyn am y pellter atgynhyrchu o'r cynradd. Ac os yw wedi cyrraedd y terfyn, peidiwch â gadael ceisiadau newydd i mewn i'r gronfa ddata, dywedwch wrth y cleient bod angen i chi ail-gychwyn cysylltiadau ac, o bosibl, dewiswch gwesteiwr arall i weithredu ceisiadau. Bydd hyn yn caniatáu i'r gronfa ddata adfer yr oedi wrth ddyblygu yn gyflym a dychwelyd eto i ymateb gydag ymholiad.
Mae'n anodd enwi'r dyddiadau gweithredu, oherwydd ei fod yn ffynhonnell agored. Ond, gobeithio, nid 2,5 mlynedd fel cydweithwyr o PgBouncer. Dyma'r nodwedd yr hoffwn ei gweld yn Odyssey.
. Nawr gallwch chi greu datganiad parod mewn dwy ffordd. Yn gyntaf, gallwch chi weithredu gorchymyn SQL, sef "parod". Er mwyn deall y gorchymyn SQL hwn, mae angen inni ddysgu sut i ddeall SQL ar ochr Bouncer. Byddai hyn yn ormodol oherwydd ei fod yn ormod gan fod angen y parser cyfan arnom. Ni allwn ddosrannu pob gorchymyn SQL.
Ond mae datganiad parod ar lefel protocol neges ar proto3. A dyma'r man pan ddaw'r wybodaeth y mae'r datganiad a baratowyd yn cael ei chreu ar ffurf strwythuredig. A gallem gefnogi'r ddealltwriaeth bod y cleient, ar ryw gysylltiad â'r gweinydd, wedi gofyn am greu datganiadau parod. A hyd yn oed os yw'r trafodiad ar gau, mae angen i ni gadw'r gweinydd a'r cleient yn gysylltiedig o hyd.
Ond yma mae anghysondeb yn y ddeialog, oherwydd mae rhywun yn dweud bod angen i chi ddeall pa ddatganiadau parod a greodd y cleient a rhannu'r cysylltiad gweinydd rhwng yr holl gleientiaid a greodd y cysylltiad gweinydd hwn, hy, a greodd ddatganiad parod o'r fath.
Dywedodd Andres Freund, pe bai cleient yn dod atoch chi a oedd eisoes wedi creu datganiad mor barod mewn cysylltiad gweinydd arall, yna ei greu iddo. Ond mae'n ymddangos ei bod ychydig yn anghywir i weithredu ymholiadau yn y gronfa ddata yn lle'r cleient, ond o safbwynt datblygwr sy'n ysgrifennu protocol ar gyfer rhyngweithio â'r gronfa ddata, byddai'n gyfleus pe bai cysylltiad rhwydwaith yn cael ei roi iddo. sydd â chais mor barod.
Ac un nodwedd arall y mae angen inni ei rhoi ar waith. Mae gennym bellach fonitro sy'n gydnaws â PgBouncer. Gallwn ddychwelyd yr amser cyflawni ymholiad cyfartalog. Ond yr amser cyfartalog yw tymheredd cyfartalog yr ysbyty: mae rhywun yn oer, mae rhywun yn gynnes - ar gyfartaledd mae pawb yn iach. Nid yw'n wir.
Mae angen inni roi cymorth ar gyfer canraddau ar waith, a fyddai’n dangos bod ceisiadau araf sy’n defnyddio adnoddau ac a fyddai’n gwneud monitro’n fwy derbyniol.
Y peth pwysicaf yw fy mod eisiau fersiwn 1.0 (Fersiwn 1.1 eisoes wedi'i ryddhau). Y ffaith yw bod Odyssey bellach yn fersiwn 1.0rc, h.y. ymgeisydd rhyddhau. Ac roedd yr holl gribin a restrais wedi'i osod yn union gyda'r un fersiwn, heblaw am y gollyngiad cof.
Beth fydd fersiwn 1.0 yn ei olygu i ni? Rydym yn cyflwyno'r Odyssey i'n canolfannau. Mae eisoes yn rhedeg ar ein cronfeydd data, ond pan fydd yn cyrraedd y pwynt o 1 o geisiadau yr eiliad, yna gallwn ddweud mai fersiwn rhyddhau yw hwn ac mae hwn yn fersiwn y gellir ei alw'n 000.
Mae sawl person yn y gymuned wedi gofyn am fwy o saib a SCRAM yn fersiwn 1.0. Ond bydd hyn yn golygu y bydd angen i ni gyflwyno'r fersiwn nesaf i'r cynhyrchiad, oherwydd nid yw SCRAM na'r saib wedi'u huno eto. Ond, yn fwyaf tebygol, bydd y mater hwn yn cael ei ddatrys yn weddol gyflym.
Rwy'n aros am eich cais tynnu. A hoffwn glywed hefyd pa broblemau sydd gennych gyda Bouncer. Gadewch i ni eu trafod. Efallai y gallwn weithredu rhai swyddogaethau sydd eu hangen arnoch.
Mae hyn yn cloi fy rhan, hoffwn glywed gennych. Diolch!
cwestiynau
Os byddaf yn rhoi fy enw cais fy hun, a fydd yn cael ei daflu'n gywir, gan gynnwys wrth gronni trafodion yn Odyssey?
Odyssey neu Bownsar?
Yn Odyssey. Mae'r Bouncer yn cael ei daflu.
Byddwn yn gwneud set.
Ac os yw fy nghysylltiad go iawn yn neidio dros gysylltiadau eraill, a fydd yn cael ei drosglwyddo?
Byddwn yn gwneud set o'r holl baramedrau a restrir. Ni allaf ddweud a yw application_name yn y rhestr hon. Ymddengys iddo ei weled yno. Byddwn yn gosod yr un paramedrau i gyd. Gydag un cais, bydd y set yn gwneud popeth a osodwyd gan y cleient yn ystod y cychwyn.
Diolch Andrey am yr adroddiad! Adroddiad da! Rwy'n falch bod Odyssey yn datblygu'n gyflymach ac yn gyflymach bob munud. Hoffwn barhau yr un peth. Rydym eisoes wedi gofyn i chi gael cysylltiad aml-ffynhonnell ddata fel y gall Odyssey gysylltu â gwahanol gronfeydd data ar yr un pryd, h.y. y caethfeistr, ac yna cysylltu'n awtomatig â'r meistr newydd ar ôl methiant.
Ydw, mae’n ymddangos fy mod yn cofio’r drafodaeth honno. Nawr mae yna sawl storfa. Ond nid oes unrhyw newid rhyngddynt. Ar ein hochr ni, rhaid inni holi'r gweinydd ei fod yn dal yn fyw a deall bod methiant wedi digwydd, pwy fydd yn galw pg_recovery. Mae gen i ffordd safonol i ddeall na ddaethom at y meistr. Ac mae'n rhaid i ni ddeall rhywsut o'r camgymeriadau neu sut? Hynny yw, mae'r syniad yn ddiddorol, mae'n cael ei drafod. Ysgrifennwch fwy o sylwadau. Os oes gennych ddwylo gweithiol sy'n adnabod C, yna mae hyn yn gyffredinol yn wych.
Mae’r mater o raddio ar draws atgynyrchiadau hefyd o ddiddordeb i ni, oherwydd rydym am wneud mabwysiadu clystyrau wedi’u hailadrodd mor syml â phosibl i ddatblygwyr ceisiadau. Ond yma hoffwn gael mwy o sylwadau, hynny yw, sut i'w wneud, sut i'w wneud yn dda.
Mae'r cwestiwn hefyd yn ymwneud â chopïau. Mae'n ymddangos bod gennych feistr a sawl atgynhyrchiad. Ac mae'n amlwg eu bod yn mynd at y replica yn llai aml nag at y meistr am gysylltiadau, oherwydd efallai bod gwahaniaeth rhyngddynt. Dywedasoch y gallai'r gwahaniaeth mewn data olygu na fydd eich busnes yn bodloni ac na fyddwch yn mynd yno nes iddo gael ei ailadrodd. Ar yr un pryd, os na wnaethoch chi fynd yno am amser hir, ac yna dechrau mynd, yna ni fydd y data sydd ei angen arnoch ar gael ar unwaith. Hynny yw, os ydym yn mynd at y meistr yn gyson, yna mae'r storfa'n cael ei gynhesu yno, ac mae'r storfa ychydig ar ei hôl hi yn y replica.
Ie ei fod yn wir. Ni fydd unrhyw flociau data yn pcache rydych chi eu heisiau, mewn storfa go iawn ni fydd unrhyw wybodaeth am y tablau rydych chi eu heisiau, ni fydd unrhyw ymholiadau wedi'u dosrannu yn y cynlluniau, dim byd o gwbl.
A phan fydd gennych chi ryw fath o glwstwr, a'ch bod chi'n ychwanegu atgynhyrchiad newydd yno, yna tra mae'n dechrau, mae popeth yn ddrwg ynddo, h.y. mae'n tyfu ei storfa.
Cefais y syniad. Y dull cywir fyddai rhedeg canran fach o ymholiadau ar y replica yn gyntaf, a fyddai'n cynhesu'r storfa. Yn fras, mae gennym amod na ddylem fod yn fwy na 10 eiliad y tu ôl i'r meistr. Ac ni ddylid cynnwys yr amod hwn mewn un don, ond yn llyfn i rai cleientiaid.
Ydy, cynyddu pwysau.
Mae hwn yn syniad da. Ond yn gyntaf mae angen i chi weithredu'r cau hwn. Yn gyntaf mae angen i ni ddiffodd, ac yna byddwn yn meddwl sut i droi ymlaen. Mae hon yn nodwedd wych i'w throi ymlaen yn esmwyth.
Mae gan nginx yr opsiwn hwn slowly start yn y clwstwr ar gyfer y gweinydd. Ac mae'n cynyddu'r llwyth yn raddol.
Ie, syniad gwych, byddwn yn rhoi cynnig arni pan fyddwn yn cyrraedd hynny.
Ffynhonnell: hab.com