Në raportin e tij, Andrey Borodin do t'ju tregojë se si ata morën parasysh përvojën e shkallëzimit të PgBouncer kur dizajnuan grupin e lidhjes , ndërsa e nxorrën në prodhim. Për më tepër, ne do të diskutojmë se cilat funksione të tërheqësit do të dëshironim të shihnim në versionet e reja: është e rëndësishme për ne jo vetëm të plotësojmë nevojat tona, por të zhvillojmë komunitetin e përdoruesve .
Video:
Pershendetje te gjitheve! Emri im është Andrew.
Në Yandex, unë zhvilloj bazat e të dhënave me burim të hapur. Dhe sot kemi një temë për lidhjet e bashkimit të lidhjeve.
Nëse dini se si të thërrisni lidhjen pooler në Rusisht, atëherë më tregoni. Unë me të vërtetë dua të gjej një term të mirë teknik që duhet të vendoset në literaturën teknike.
Tema është mjaft e ndërlikuar, sepse në shumë baza të të dhënave, bashkuesi i lidhjes është i integruar dhe as nuk keni nevojë të dini për të. Sigurisht, ka disa cilësime kudo, por në Postgres nuk funksionon kështu. Dhe paralelisht (në HighLoad++ 2019) ekziston një raport nga Nikolai Samokhvalov për vendosjen e pyetjeve në Postgres. Dhe siç e kuptoj unë, këtu erdhën njerëz të cilët tashmë i kishin konfiguruar pyetjet e tyre në mënyrë të përsosur, dhe këta janë njerëz që përballen me probleme më të rralla të sistemit që lidhen me rrjetin dhe përdorimin e burimeve. Dhe në disa vende mund të jetë mjaft e vështirë në kuptimin që problemet nuk janë të dukshme.
Yandex ka Postgres. Shumë shërbime Yandex jetojnë në Yandex.Cloud. Dhe ne kemi disa petabajt të dhëna që gjenerojnë të paktën një milion kërkesa në sekondë në Postgres.
Dhe ne ofrojmë një grup mjaft standard për të gjitha shërbimet - kjo është nyja kryesore kryesore e nyjes, dy kopjet e zakonshme (sinkrone dhe asinkrone), kopje rezervë, shkallëzimi i kërkesave të leximit në kopje.
Çdo nyje klaster është Postgres, në të cilën, përveç Postgres dhe sistemeve të monitorimit, është instaluar edhe një bashkues lidhjesh. Pooleri lidhës përdoret për rrethim dhe për qëllimin e tij kryesor.
Cili është qëllimi kryesor i bashkimit të lidhjes?
Postgres miraton një model procesi kur punon me një bazë të dhënash. Kjo do të thotë që një lidhje është një proces, një prapavijë e Postgres. Dhe në këtë backend ka shumë cache të ndryshme, të cilat janë mjaft të shtrenjta për t'i bërë të ndryshme për lidhje të ndryshme.
Për më tepër, kodi Postgres ka një grup të quajtur procArray. Ai përmban të dhëna bazë për lidhjet e rrjetit. Dhe pothuajse të gjithë algoritmet e përpunimit procArray kanë kompleksitet linear; ato drejtojnë të gjithë grupin e lidhjeve të rrjetit. Është një cikël mjaft i shpejtë, por me më shumë lidhje të rrjetit në hyrje gjërat bëhen pak më të shtrenjta. Dhe kur gjërat bëhen pak më të shtrenjta, mund të përfundoni duke paguar një çmim shumë të lartë për shumë lidhje rrjeti.
Ka 3 qasje të mundshme:
- Në anën e aplikimit.
- Në anën e bazës së të dhënave.
- Dhe midis, domethënë, të gjitha llojet e kombinimeve.
Fatkeqësisht, pooleri i integruar është aktualisht në zhvillim e sipër. Miqtë tanë në PostgreSQL Professional e bëjnë këtë kryesisht. Kur do të shfaqet është e vështirë të parashikohet. Dhe në fakt, ne kemi dy zgjidhje që arkitekti të zgjedhë. Këto janë grupi nga ana e aplikacionit dhe grupi përfaqësues.
Pishina në anën e aplikimit është mënyra më e lehtë. Dhe pothuajse të gjithë drejtuesit e klientëve ju ofrojnë një mënyrë: paraqisni miliona lidhjet tuaja në kod si disa duzina lidhje me bazën e të dhënave.
Problemi që lind është se në një pikë të caktuar ju dëshironi të shkallëzoni backend-in, dëshironi ta vendosni atë në shumë makina virtuale.
Pastaj kupton se ke disa zona të tjera disponueshmërie, disa qendra të dhënash. Dhe qasja e bashkimit nga ana e klientit çon në numra më të mëdhenj. Ato të mëdha janë rreth 10 lidhje. Ky është skaji që mund të funksionojë normalisht.
Nëse flasim për proxy poolers, atëherë ka dy grupues që mund të bëjnë shumë gjëra. Ata nuk janë vetëm poolers. Ata janë poolers + funksionalitet më të lezetshëm. Kjo и .
Por, për fat të keq, jo të gjithë kanë nevojë për këtë funksion shtesë. Dhe kjo çon në faktin se grupuesit mbështesin vetëm bashkimin e sesioneve, d.m.th., një klient hyrës, një klient dalës në bazën e të dhënave.
Kjo nuk është shumë e përshtatshme për qëllimet tona, kështu që ne përdorim PgBouncer, i cili zbaton bashkimin e transaksioneve, d.m.th., lidhjet e serverit përputhen me lidhjet e klientit vetëm për kohëzgjatjen e transaksionit.
Dhe në ngarkesën tonë të punës, kjo është e vërtetë. Por ka disa probleme.
Problemet fillojnë kur doni të diagnostikoni një seancë, sepse të gjitha lidhjet tuaja hyrëse janë lokale. Të gjithë erdhën me një loopback dhe disi bëhet e vështirë të gjurmosh seancën.
Sigurisht që mund të përdorni aplikacionin_name_add_host. Kjo është një mënyrë në anën e Bouncer për të shtuar një adresë IP në emrin e aplikacionit. Por aplikacioni_emri caktohet nga një lidhje shtesë.
Në këtë grafik, ku vija e verdhë është kërkesa reale, dhe ku vija blu janë kërkesat që fluturojnë në bazën e të dhënave. Dhe ky ndryshim është pikërisht instalimi i application_name, i cili nevojitet vetëm për gjurmim, por nuk është aspak falas.
Përveç kësaj, në Bouncer nuk mund të kufizoni një grup, d.m.th. numrin e lidhjeve të bazës së të dhënave për përdorues specifik, për bazë të dhënash specifike.
Në çfarë çon kjo? Ju keni një shërbim të ngarkuar të shkruar në C++ dhe diku afër një shërbim të vogël në një nyje që nuk bën asgjë të tmerrshme me bazën e të dhënave, por drejtuesi i tij çmendet. Hap 20 lidhje dhe gjithçka tjetër do të presë. Edhe kodi juaj është normal.
Natyrisht, ne shkruam një patch të vogël për Bouncer që shtoi këtë cilësim, d.m.th. duke kufizuar klientët në pishinë.
Do të ishte e mundur ta bëni këtë në anën e Postgres, d.m.th., të kufizoni rolet në bazën e të dhënave me numrin e lidhjeve.
Por atëherë ju humbni aftësinë për të kuptuar pse nuk keni lidhje me serverin. PgBouncer nuk hedh një gabim lidhjeje, ai gjithmonë kthen të njëjtin informacion. Dhe nuk mund ta kuptoni: mbase fjalëkalimi juaj ka ndryshuar, ndoshta baza e të dhënave sapo ka humbur, mbase diçka nuk është në rregull. Por nuk ka një diagnozë. Nëse një seancë nuk mund të krijohet, nuk do ta dini pse nuk mund të themelohet.
Në një moment të caktuar, ju shikoni grafikët e aplikacionit dhe shihni që aplikacioni nuk po funksionon.
Shikoni lart dhe shikoni që Gënjeshtari është me një fije. Kjo është një pikë kthese në jetën e shërbimit. Ju e kuptoni se po përgatiteshit për të shkallëzuar bazën e të dhënave në një vit e gjysmë, dhe ju duhet të shkallëzoni më shumë.
Ne kemi arritur në përfundimin se kemi nevojë për më shumë PgBouncer.
Gënjeshtari është rregulluar pak.
Dhe ata e bënë atë në mënyrë që disa Bouncer të mund të ngriheshin duke ripërdorur portin TCP. Dhe sistemi operativ transferon automatikisht lidhjet hyrëse TCP ndërmjet tyre duke përdorur "Round-robin".
Kjo është transparente për klientët, që do të thotë se duket sikur keni një Bouncer, por keni fragmentim të lidhjeve boshe midis ekzekutimit të Bouncers.
Dhe në një moment të caktuar ju mund të vini re se këta 3 Gënjeshtarë secili hanë thelbin e tyre me 100%. Ju nevojiten mjaft gënjeshtarë. Pse?
Sepse ju keni TLS. Ju keni një lidhje të koduar. Dhe nëse krahasoni Postgres me dhe pa TLS, do të zbuloni se numri i lidhjeve të vendosura bie me pothuajse dy rend të madhësisë me enkriptimin e aktivizuar, sepse shtrëngimi i duarve TLS konsumon burimet e CPU.
Dhe në krye mund të shihni mjaft funksione kriptografike që ekzekutohen kur ka një valë lidhjesh hyrëse. Meqenëse primarja jonë mund të kalojë midis zonave të disponueshmërisë, një valë lidhjesh hyrëse është një situatë mjaft tipike. Kjo do të thotë, për disa arsye primarja e vjetër nuk ishte e disponueshme, e gjithë ngarkesa u dërgua në një qendër tjetër të të dhënave. Ata do të vijnë të gjithë për t'i përshëndetur TLS në të njëjtën kohë.
Dhe një numër i madh i shtrëngimeve duarsh TLS mund të mos i thonë më përshëndetje Gënjeshtarit, por do t'i shtrëngojnë fytin. Për shkak të afatit kohor, vala e lidhjeve hyrëse mund të bëhet e pashuar. Nëse provoni përsëri në bazën pa prapambetje eksponenciale, ato nuk do të vijnë përsëri dhe përsëri në një valë koherente.
Këtu është një shembull i 16 PgBouncers që ngarkojnë 16 bërthama në 100%.
Erdhëm në kaskadën PgBouncer. Ky është konfigurimi më i mirë që mund të arrihet në ngarkesën tonë me Bouncer. Bouncer-ët tanë të jashtëm përdoren për shtrëngimin e duarve TCP, dhe Bouncer-et e brendshëm përdoren për bashkim real, në mënyrë që të mos fragmentohen shumë lidhjet e jashtme.
Në këtë konfigurim, një rinisje e qetë është e mundur. Ju mund të rinisni të gjitha këto 18 Bouncers një nga një. Por ruajtja e një konfigurimi të tillë është mjaft e vështirë. Sysadmins, DevOps dhe njerëzit që janë në të vërtetë përgjegjës për këtë server nuk do të jenë shumë të kënaqur me këtë marrëveshje.
Duket se të gjitha përmirësimet tona mund të promovohen në burim të hapur, por Bouncer nuk mbështetet shumë mirë. Për shembull, aftësia për të ekzekutuar disa PgBouncer në një port u krye një muaj më parë. Kishte një kërkesë për tërheqje me këtë veçori disa vite më parë.
Ose një shembull më shumë. Në Postgres, mund të anuloni një kërkesë në vazhdim duke e dërguar sekretin në një lidhje tjetër pa vërtetim të panevojshëm. Por disa klientë thjesht dërgojnë një rivendosje TCP, d.m.th. ata prishin lidhjen e rrjetit. Çfarë do të bëjë Bouncer? Ai nuk do të bëjë asgjë. Ajo do të vazhdojë të ekzekutojë kërkesën. Nëse keni marrë një numër të madh lidhjesh që kanë krijuar një bazë të dhënash me kërkesa të vogla, atëherë thjesht shkëputja e lidhjes nga Bouncer nuk do të jetë e mjaftueshme; ju gjithashtu duhet të plotësoni ato kërkesa që janë duke u ekzekutuar në bazën e të dhënave.
Kjo është rregulluar dhe ky problem nuk është bashkuar ende në rrjedhën e sipërme të Bouncer.
Dhe kështu arritëm në përfundimin se ne kemi nevojë për bashkimin tonë të lidhjes, i cili do të zhvillohet, rregullohet, në të cilin problemet mund të korrigjohen shpejt dhe që, natyrisht, duhet të jetë me shumë fije.
Ne vendosëm multithreading si detyrë kryesore. Ne duhet të jemi në gjendje të trajtojmë mirë valën e lidhjeve hyrëse TLS.
Për ta bërë këtë, ne duhej të zhvillonim një bibliotekë të veçantë të quajtur Machinarium, e cila është krijuar për të përshkruar gjendjet e makinës të një lidhjeje rrjeti si kod sekuencial. Nëse shikoni kodin burimor libpq, do të shihni disa telefonata mjaft komplekse që mund t'ju kthejnë një rezultat dhe thonë: "Më telefono më vonë. Për momentin kam IO për momentin, por kur IO të ikë, do të kem një ngarkesë në procesor.” Dhe kjo është një skemë me shumë nivele. Komunikimi në rrjet zakonisht përshkruhet nga një makinë shtetërore. Shumë rregulla si "Nëse më parë kam marrë një kokë pakete me madhësi N, tani jam duke pritur për N bajt", "Nëse kam dërguar një paketë SYNC, tani jam duke pritur për një paketë me meta të dhëna rezultati". Rezultati është një kod mjaft i vështirë, kundërintuitiv, sikur labirinti të ishte konvertuar në skanim të linjës. Ne e bëmë atë në mënyrë që në vend të një makine shtetërore, programuesi përshkruan rrugën kryesore të ndërveprimit në formën e kodit të zakonshëm imperativ. Vetëm se në këtë kod imperativ duhet të futni vendet ku sekuenca e ekzekutimit duhet të ndërpritet duke pritur të dhëna nga rrjeti, duke kaluar kontekstin e ekzekutimit në një korutinë tjetër (fije jeshile). Kjo qasje është e ngjashme me faktin që ne shkruajmë rrugën më të pritur në labirint me radhë, dhe më pas shtojmë degë në të.
Si rezultat, ne kemi një thread që pranon TCP dhe round-robin ua kalon lidhjen TPC shumë punëtorëve.
Në këtë rast, çdo lidhje klienti funksionon gjithmonë në një procesor. Dhe kjo ju lejon ta bëni atë miqësore me cache.
Dhe përveç kësaj, ne kemi përmirësuar pak grumbullimin e paketave të vogla në një paketë të madhe në mënyrë që të lehtësojmë grupin TCP të sistemit.
Përveç kësaj, ne kemi përmirësuar bashkimin e transaksioneve në kuptimin që Odyssey, kur konfigurohet, mund të dërgojë ANULIM dhe RISHTIM në rast të dështimit të lidhjes së rrjetit, d.m.th. nëse askush nuk pret për një kërkesë, Odyssey do t'i thotë bazës së të dhënave të mos përpiqet të plotësoni kërkesën që mund të shpërdorojë burime të çmuara.
Dhe sa herë që është e mundur, ne mbajmë lidhje me të njëjtin klient. Kjo shmang nevojën për të riinstaluar aplikacionin_name_add_host. Nëse kjo është e mundur, atëherë nuk kemi pse të rivendosim shtesë parametrat që nevojiten për diagnostikim.
Ne punojmë në interes të Yandex.Cloud. Dhe nëse përdorni PostgreSQL të menaxhuar dhe keni të instaluar një bashkues lidhjesh, mund të krijoni përsëritje logjike nga jashtë, d.m.th., të na lini, nëse dëshironi, duke përdorur replikimin logjik. Gënjeshtari nuk do të lëshojë rrjedhën logjike të përsëritjes jashtë.
Ky është një shembull i konfigurimit të përsëritjes logjike.
Përveç kësaj, ne kemi mbështetje për replikimin fizik nga jashtë. Në Cloud, natyrisht, kjo është e pamundur, sepse atëherë grupi do t'ju japë shumë informacion për veten e tij. Por në instalimet tuaja, nëse keni nevojë për përsëritje fizike përmes bashkuesit të lidhjes në Odyssey, kjo është e mundur.
Odyssey ka monitorim plotësisht të pajtueshëm me PgBouncer. Ne kemi të njëjtën konsolë që ekzekuton pothuajse të gjitha komandat e njëjta. Nëse diçka mungon, dërgoni një kërkesë tërheqjeje, ose të paktën një problem në GitHub dhe ne do të plotësojmë komandat e nevojshme. Por ne tashmë kemi funksionalitetin kryesor të konzollës PgBouncer.
Dhe, sigurisht, kemi gabim në përcjelljen. Ne do të kthejmë gabimin e raportuar nga baza e të dhënave. Do të merrni informacione se pse nuk jeni përfshirë në bazën e të dhënave, dhe jo vetëm se nuk jeni përfshirë në të.
Ky funksion çaktivizohet në rast se keni nevojë për përputhshmëri 100% me PgBouncer. Ne mund të sillemi në të njëjtën mënyrë si Gënjeshtari, vetëm për të qenë në anën e sigurt.
Разработка
Disa fjalë për kodin burimor Odisea.
Për shembull, ka komanda "Ndalo / Rifillo". Ato zakonisht përdoren për të përditësuar bazën e të dhënave. Nëse keni nevojë të përditësoni Postgres, atëherë mund ta ndaloni atë në grupin e lidhjes, bëni pg_upgrade dhe më pas rifilloni. Dhe nga ana e klientit do të duket sikur baza e të dhënave thjesht po ngadalësohej. Ky funksionalitet na u soll nga njerëz nga komuniteti. Ajo nuk është ende e ngrirë, por së shpejti gjithçka do të jetë. (Tashmë i ngrirë)
- tashmë i ngrirë
Për më tepër, një nga veçoritë e reja në PgBouncer është mbështetja për Autentifikimin SCRAM, i cili gjithashtu na u soll nga një person që nuk punon në Yandex.Cloud. Të dyja janë funksionale komplekse dhe të rëndësishme.
Prandaj, do të doja t'ju tregoja se nga është krijuar Odisea, në rast se edhe ju dëshironi të shkruani një kod të vogël tani.
Ju keni bazën burimore Odyssey, e cila mbështetet në dy biblioteka kryesore. Biblioteka Kiwi është një zbatim i protokollit të mesazheve Postgres. Kjo do të thotë, proto 3 amtare e Postgres është mesazhe standarde që mund të shkëmbejnë pjesët e përparme dhe të pasme. Ato zbatohen në bibliotekën Kiwi.
Biblioteka Machinarium është një bibliotekë e zbatimit të temave. Një fragment i vogël i këtij Machinarium është shkruar në gjuhën e asamblesë. Por mos u shqetësoni, janë vetëm 15 rreshta.
Arkitektura e Odisesë. Ekziston një makinë kryesore në të cilën funksionojnë korutinat. Kjo makinë zbaton pranimin e lidhjeve hyrëse TCP dhe shpërndarjen e tyre midis punëtorëve.
Një mbajtës për disa klientë mund të punojë brenda një punonjësi. Fillimi kryesor drejton gjithashtu konsolën dhe përpunimin e detyrave të kroneve për të fshirë lidhjet që nuk nevojiten më në grup.
Odyssey testohet duke përdorur paketën standarde të testeve Postgres. Ne thjesht kryejmë kontrollin e instalimit përmes Bouncer dhe përmes Odyssey, marrim një div null. Ka disa teste që lidhen me formatimin e datave që nuk kalojnë saktësisht njësoj në Bouncer dhe në Odyssey.
Përveç kësaj, ka shumë shoferë që kanë testimin e tyre. Dhe ne përdorim testet e tyre për të testuar Odisenë.
Përveç kësaj, për shkak të konfigurimit tonë të kaskadës, ne duhet të testojmë paketa të ndryshme: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey në mënyrë që të jemi të sigurt se nëse Odisea përfundon në ndonjë nga pjesët në kaskadë, gjithashtu funksionon akoma. siç presim.
grabujë
Ne përdorim Odisenë në prodhim. Dhe nuk do të ishte e drejtë nëse do të thosha se gjithçka funksionon. Jo, pra, po, por jo gjithmonë. Për shembull, në prodhim gjithçka thjesht funksionoi, atëherë erdhën miqtë tanë nga PostgreSQL Professional dhe thanë që kishim një rrjedhje memorie. Ata vërtet ishin, ne i korrigjuam. Por ishte e thjeshtë.
Më pas zbuluam se bashkuesi i lidhjes ka lidhje hyrëse TLS dhe lidhje TLS dalëse. Dhe lidhjet kërkojnë certifikata klienti dhe certifikata serveri.
Certifikatat e serverit Bouncer dhe Odyssey rilexohen nga pcache-ja e tyre, por certifikatat e klientit nuk kanë nevojë të rilexohen nga pcache, sepse Odisea jonë e shkallëzueshme përfundimisht shkon në performancën e sistemit të leximit të kësaj certifikate. Kjo na erdhi si befasi, sepse atij nuk iu desh shumë kohë për të rezistuar. Në fillim u shkallëzua në mënyrë lineare, por pas 20 lidhjeve hyrëse të njëkohshme ky problem u shfaq.
Metoda e Autentifikimit të Pluggable është aftësia për të vërtetuar duke përdorur mjete të integruara Lunux. Në PgBouncer ai zbatohet në atë mënyrë që ka një thread të veçantë për të pritur një përgjigje nga PAM dhe ekziston një thread kryesor PgBouncer që shërben lidhjen aktuale dhe mund t'u kërkojë atyre të jetojnë në thread-in PAM.
Ne nuk e zbatuam këtë për një arsye të thjeshtë. Ne kemi shumë fije. Pse na duhet kjo?
Kjo përfundimisht mund të krijojë probleme në atë që nëse keni vërtetim PAM dhe autentikim jo-PAM, atëherë një valë e madhe e vërtetimit PAM mund të vonojë ndjeshëm vërtetimin jo-PAM. Kjo është një nga ato gjëra që ne nuk e kemi rregulluar. Por nëse doni ta rregulloni, mund ta bëni këtë.
Një tjetër raketë ishte se ne kemi një thread që pranon të gjitha lidhjet hyrëse. Dhe më pas ata transferohen në pishinën e punëtorëve, ku do të bëhet shtrëngimi i duarve TLS.
Në fund të fundit, nëse keni një valë koherente prej 20 lidhjesh rrjeti, ato do të pranohen të gjitha. Dhe në anën e klientit, libpq do të fillojë të raportojë afate kohore. Si parazgjedhje duket të jetë 000 sekonda.
Nëse të gjithë nuk mund të hyjnë në bazën e të dhënave në të njëjtën kohë, atëherë ata nuk mund të hyjnë në bazën e të dhënave, sepse e gjithë kjo mund të mbulohet me riprovim jo-eksponencial.
Ne arritëm në përfundimin se kopjuam skemën nga PgBouncer këtu me faktin se kemi frenim të numrit të lidhjeve TCP të cilat ne i pranojmë.
Nëse shohim se po pranojmë lidhje, por në fund të fundit nuk kanë kohë për të shtrënguar duart, i vendosim në një radhë që të mos harxhojnë burimet e CPU-së. Kjo çon në faktin se një shtrëngim duarsh i njëkohshëm mund të mos kryhet për të gjitha lidhjet që kanë mbërritur. Por të paktën dikush do të hyjë në bazën e të dhënave, edhe nëse ngarkesa është mjaft e rëndë.
Udhërrëfyesi
Çfarë do të dëshironit të shihnit në të ardhmen në Odisea? Çfarë jemi gati të zhvillojmë veten dhe çfarë presim nga komuniteti?
Që nga gushti 2019.
Ja si dukej udhërrëfyesi i Odisesë në gusht:
- Ne donim vërtetimin SCRAM dhe PAM.
- Ne donim t'i përcillnim kërkesat për leximin në gatishmëri.
- Unë do të doja një rinisje në internet.
- Dhe aftësia për të ndaluar në server.
Gjysma e këtij udhërrëfyesi është përfunduar dhe jo nga ne. Dhe kjo është e mirë. Pra, le të diskutojmë atë që mbetet dhe të shtojmë më shumë.
? Ne kemi kopje që thjesht do të ngrohin ajrin pa ekzekutuar kërkesa. Ne kemi nevojë që ata të ofrojnë dështim dhe kalim. Në rast të problemeve në një nga qendrat e të dhënave, do të doja t'i merrja ato me një punë të dobishme. Sepse ne nuk mund të konfigurojmë të njëjtët procesorë qendrorë, të njëjtën memorie ndryshe, sepse përndryshe replikimi nuk do të funksionojë.
Në parim, në Postgres, duke filluar nga 10, është e mundur të specifikoni session_attrs kur lidheni. Ju mund të listoni të gjithë hostet e bazës së të dhënave në lidhje dhe të thoni pse po shkoni në bazën e të dhënave: shkruani ose lexoni vetëm. Dhe vetë shoferi do të zgjedhë hostin e parë në listë që i pëlqen më shumë, i cili plotëson kërkesat e session_attrs.
Por problemi me këtë qasje është se ajo nuk kontrollon vonesën e replikimit. Ju mund të keni ndonjë kopje që ka mbetur prapa për një kohë të papranueshme për shërbimin tuaj. Për të mundësuar ekzekutimin me funksione të plota të pyetjeve të leximit në një kopje, në thelb duhet të mbështesim aftësinë e Odyssey për të mos ekzekutuar kur nuk mund të lexohet.
Odisea duhet të shkojë herë pas here në bazën e të dhënave dhe të kërkojë distancën e replikimit nga primarja. Dhe nëse ka arritur vlerën kufi, mos lejoni kërkesa të reja në bazën e të dhënave, tregoni klientit se duhet të rifillojë lidhjet dhe, ndoshta, të zgjedhë një host tjetër për të ekzekutuar kërkesat. Kjo do të lejojë bazën e të dhënave të rivendosë shpejt vonesën e riprodhimit dhe të kthehet përsëri për t'iu përgjigjur me një kërkesë.
Është e vështirë të jepet një kornizë kohore për zbatimin, sepse është me burim të hapur. Por, shpresoj, jo 2,5 vjet si kolegët e mi nga PgBouncer. Ky është tipari që do të doja të shihja në Odisea.
. Tani mund të krijoni një deklaratë të përgatitur në dy mënyra. Së pari, mund të ekzekutoni komandën SQL, përkatësisht "prepared". Për të kuptuar këtë komandë SQL, ne duhet të mësojmë të kuptojmë SQL në anën e Bouncer. Kjo do të ishte një tepricë, sepse është e tepërt, pasi ne kemi nevojë për të gjithë analizuesin. Ne nuk mund të analizojmë çdo komandë SQL.
Por ekziston një deklaratë e përgatitur në nivelin e protokollit të mesazhit në proto3. Dhe ky është vendi kur informacioni që po krijohet një deklaratë e përgatitur vjen në një formë të strukturuar. Dhe ne mund të mbështesim të kuptuarit se në disa lidhje serveri klienti kërkoi të krijonte deklarata të përgatitura. Dhe edhe nëse transaksioni është i mbyllur, ne ende duhet të ruajmë lidhjen midis serverit dhe klientit.
Por këtu lind një mospërputhje në dialog, sepse dikush thotë që ju duhet të kuptoni se çfarë lloj deklaratash të përgatitura krijoi klienti dhe të ndani lidhjen e serverit midis të gjithë klientëve që krijuan këtë lidhje serveri, d.m.th., kush krijoi një deklaratë të tillë të përgatitur.
Andres Freund tha që nëse një klient vjen tek ju i cili tashmë ka krijuar një deklaratë të tillë të përgatitur në një lidhje tjetër serveri, atëherë krijoni atë për të. Por duket pak e gabuar të ekzekutosh pyetje në bazën e të dhënave në vend të klientit, por nga këndvështrimi i zhvilluesit që shkruan protokollin për ndërveprim me bazën e të dhënave, do të ishte i përshtatshëm nëse atij thjesht do t'i jepej një lidhje rrjeti në të cilën ekziston një pyetje e tillë e përgatitur.
Dhe një veçori tjetër që duhet të zbatojmë. Tani kemi monitorim të pajtueshëm me PgBouncer. Mund të kthejmë kohën mesatare të ekzekutimit të pyetjes. Por koha mesatare është temperatura mesatare në spital: disa janë të ftohtë, disa janë të ngrohtë - mesatarisht, të gjithë janë të shëndetshëm. Nuk eshte e vertete.
Ne duhet të zbatojmë mbështetje për përqindjet që do të tregonin se ka pyetje të ngadalta që po harxhojnë burime dhe e bëjnë monitorimin më të pranueshëm.
Gjëja më e rëndësishme është që unë dua versionin 1.0 (Versioni 1.1 tashmë është lëshuar). Fakti është se Odyssey tani është në versionin 1.0rc, pra kandidati i lëshimit. Dhe të gjitha problemet që listova u rregulluan me të njëjtin version, përveç rrjedhjes së kujtesës.
Çfarë do të thotë versioni 1.0 për ne? Ne po e shpërndajmë Odisenë në bazat tona. Ai tashmë po funksionon në bazat tona të të dhënave, por kur arrin pikën e 1 kërkesave në sekondë, atëherë mund të themi se ky është versioni i lëshimit dhe ky është një version që mund të quhet 000.
Disa njerëz në komunitet kanë kërkuar që versioni 1.0 të përfshijë pauzë dhe SCRAM. Por kjo do të thotë se ne do të duhet të nxjerrim versionin e ardhshëm në prodhim, sepse as SCRAM dhe as pauza nuk janë vrarë ende. Por, ka shumë të ngjarë, kjo çështje do të zgjidhet mjaft shpejt.
Unë jam duke pritur për kërkesën tuaj për tërheqje. Do të doja gjithashtu të dëgjoja se çfarë problemesh keni me Bouncer. Le t'i diskutojmë ato. Ndoshta ne mund të zbatojmë disa funksione që ju nevojiten.
Ky është fundi i pjesës sime, do të doja t'ju dëgjoja. Faleminderit!
Pyetjet tuaja
Nëse caktoj emrin tim të aplikacionit, a do të përcillet saktë, duke përfshirë bashkimin e transaksioneve në Odyssey?
Odisea apo Gënjeshtar?
Në Odisenë. Në Gënjeshtar është hedhur.
Ne do të bëjmë një set.
Dhe nëse lidhja ime e vërtetë kërcen në lidhje të tjera, a do të transmetohet?
Ne do të bëjmë një grup të të gjithë parametrave që janë të listuar në listë. Nuk mund të them nëse aplikacioni_emri është në këtë listë. Mendoj se e pashë atje. Ne do të vendosim të gjithë parametrat e njëjtë. Me një kërkesë, grupi do të bëjë gjithçka që është instaluar nga klienti gjatë fillimit.
Faleminderit, Andrey, për raportin! Raport i mirë! Më vjen mirë që Odisea po zhvillohet çdo minutë më shpejt dhe më shpejt. Unë dua të vazhdoj kështu. Ne ju kemi kërkuar tashmë që të keni një lidhje me shumë burime të dhënash në mënyrë që Odyssey të mund të lidhet me baza të të dhënave të ndryshme njëkohësisht, d.m.th. një skllav kryesor dhe më pas të lidhet automatikisht me një master të ri pas dështimit.
Po, më duket se e mbaj mend këtë diskutim. Tani ka disa depo. Por nuk ka asnjë ndryshim midis tyre. Nga ana jonë, ne duhet të anketojmë serverin që ai është ende i gjallë dhe të kuptojmë se ka ndodhur një dështim, kush do të thërrasë pg_recovery. Unë kam një mënyrë standarde për të kuptuar se ne nuk kemi ardhur te mjeshtri. Dhe a duhet të kuptojmë disi nga gabimet apo çfarë? Dmth ideja është interesante, po diskutohet. Shkruani më shumë komente. Nëse keni punëtorë që dinë C, atëherë kjo është e mrekullueshme.
Çështja e shkallëzimit nëpër kopje është gjithashtu me interes për ne, sepse ne duam ta bëjmë adoptimin e grupeve të përsëritura sa më të thjeshtë që të jetë e mundur për zhvilluesit e aplikacioneve. Por këtu do të doja më shumë komente, d.m.th., saktësisht si ta bëjmë, si ta bëjmë mirë.
Pyetja ka të bëjë edhe me kopjet. Rezulton se keni një mjeshtër dhe disa kopje. Dhe është e qartë që ata shkojnë në replikë më rrallë se tek master për lidhje, sepse mund të kenë dallime. Ju thatë se ndryshimi në të dhëna mund të jetë i tillë që nuk do të kënaqë biznesin tuaj dhe nuk do të shkoni atje derisa të përsëritet. Në të njëjtën kohë, nëse nuk keni shkuar atje për një kohë të gjatë dhe më pas keni filluar të shkoni, atëherë të dhënat që nevojiten nuk do të jenë menjëherë të disponueshme. Kjo do të thotë, nëse shkojmë vazhdimisht te masteri, atëherë cache-i atje ngrohet, por në kopje cache mbetet pak.
Po është e vërtetë. Pcache nuk do të ketë blloqet e të dhënave që dëshironi, cache e vërtetë nuk do të ketë informacion për tabelat që dëshironi, planet nuk do të kenë pyetje të analizuara, nuk do të ketë asgjë fare.
Dhe kur keni një lloj grupi, dhe shtoni një kopje të re atje, atëherë ndërsa fillon, gjithçka është e keqe në të, d.m.th. rrit cache-in e saj.
E mora idenë. Qasja e saktë do të ishte që fillimisht të ekzekutohej një përqindje e vogël e pyetjeve në kopje, e cila do të ngrohte cache. Përafërsisht, ne kemi një kusht që duhet të mbetemi pas mjeshtrit jo më shumë se 10 sekonda. Dhe kjo gjendje nuk përfshihet në një valë, por pa probleme për disa klientë.
Po, rrit peshën.
Kjo është një ide e mirë. Por së pari ne duhet të zbatojmë këtë mbyllje. Së pari duhet të fikim, dhe më pas do të mendojmë se si të ndizemi. Ky është një veçori e shkëlqyer për ta aktivizuar pa probleme.
Nginx e ka këtë opsion slowly start në një grup për serverin. Dhe ai gradualisht rrit ngarkesën.
Po, ide e mrekullueshme, do ta provojmë kur ta arrijmë.
Burimi: www.habr.com