Bere txostenean, Andrey Borodin-ek esango du nola hartu zuten kontuan PgBouncer eskalatzearen esperientzia konexio-bilgailua diseinatzerakoan. , ekoizpenera zabaldu zutenean. Horrez gain, tiratzailearen zein funtzio ikusi nahiko genituzkeen bertsio berrietan eztabaidatuko dugu: gure beharrak asetzeaz gain, erabiltzaileen komunitatea garatzea garrantzitsua da. .
Video:
Kaixo guztioi! Nire izena Andrew da.
Yandex-en, kode irekiko datu-baseak garatzen ditut. Eta gaur konexio pooler konexioei buruzko gaia dugu.
Errusieraz konexio pooler deitzen badakizu, esan iezadazu. Benetan nahi dut literatura teknikoan ezarri beharreko termino tekniko on bat aurkitu.
Gaia nahiko korapilatsua da, datu-base askotan konexio-biltzailea barneratuta dagoelako eta ez duzulako horren berri jakin behar. Noski, ezarpen batzuk daude nonahi, baina Postgres-en ez da horrela funtzionatzen. Eta paraleloan (HighLoad++ 2019-n) Nikolai Samokhvalov-en txosten bat dago Postgres-en kontsultak ezartzeari buruz. Eta ulertzen dudanez, kontsultak lehendik primeran konfiguratuta zituen jendea etorri zen hona, eta sarearen eta baliabideen erabilerarekin lotutako sistema arazo arraroen aurrean dauden pertsonak dira. Eta leku batzuetan nahiko zaila izan liteke arazoak nabariak ez direnean.
Yandexek Postgres dauka. Yandex zerbitzu asko Yandex.Cloud-en bizi dira. Eta Postgres-en gutxienez milioi bat eskaera sortzen dituzten hainbat petabyte datu ditugu segundoko.
Eta zerbitzu guztietarako kluster nahiko estandarra eskaintzen dugu - hau da nodoaren nodo nagusia, ohiko bi erreplikak (sinkronoak eta asinkronoak), babeskopia, erreplikaren irakurketa-eskaeren eskalatzea.
Kluster-nodo bakoitza Postgres da, eta bertan, Postgres eta monitorizazio-sistemez gain, konexio-biltzaile bat ere instalatzen da. Connection pooler hesietarako eta bere helburu nagusirako erabiltzen da.
Zein da konexio pooler-en helburu nagusia?
Postgres-ek prozesu-eredu bat hartzen du datu-base batekin lan egiten duenean. Horrek esan nahi du konexio bat prozesu bat dela, Postgres backend bat. Eta backend honetan cache ezberdin asko daude, konexio ezberdinetarako desberdinak egitea nahiko garestiak.
Gainera, Postgres kodeak procArray izeneko array bat du. Sareko konexioei buruzko oinarrizko datuak ditu. Eta procArray prozesatzeko algoritmo ia guztiek konplexutasun lineala dute; sareko konexioen multzo osoan zehar exekutatzen dute. Nahiko ziklo azkarra da, baina sarrerako sare-konexio gehiagorekin gauzak apur bat garestitzen dira. Eta gauzak apur bat garestitzen direnean, sare-konexio askogatik oso prezio altua ordain dezakezu.
3 planteamendu posible daude:
- Aplikazioaren aldetik.
- Datu-basearen aldean.
- Eta artean, hau da, era guztietako konbinazioak.
Zoritxarrez, eraikitako pooler garatzen ari da. PostgreSQL Professional-eko gure lagunek hori egiten dute batez ere. Noiz agertuko den zaila da aurreikustea. Eta hain zuzen ere, bi irtenbide ditugu arkitektoak aukeran. Hauek aplikazioen alboko igerilekua eta proxy igerilekua dira.
Aplikazioaren alboko igerilekua da biderik errazena. Eta ia bezero-gidari guztiek bide bat eskaintzen dizute: zure milioika konexio kodean aurkeztu datu-baserako hainbat dozena konexio gisa.
Sortzen den arazoa da une jakin batean backend-a eskalatu nahi duzula, makina birtual askotan zabaldu nahi duzula.
Orduan konturatzen zara hainbat erabilgarritasun gune gehiago dituzula, hainbat datu-zentro. Eta bezeroen alde bateratzearen ikuspegiak kopuru handiagoak ekartzen ditu. Handiak 10 konexio inguru dira. Hau da normalean lan egin dezakeen ertza.
Proxy poolers hitz egiten badugu, badaude bi poolers gauza asko egin ditzaketenak. Ez dira pool-er bakarrik. Poolers + funtzionaltasun coolagoak dira. Hau ΠΈ .
Baina, zoritxarrez, denek ez dute funtzionalitate osagarri hau behar. Eta poolers-ek saioen bilketa soilik onartzen duela dakar, hau da, sarrerako bezero bat, irteerako bezero bat datu-basera.
Hau ez da oso egokia gure helburuetarako, beraz, PgBouncer erabiltzen dugu, transakzioen bilketa ezartzen duena, hau da, zerbitzari-konexioak bezero-konexioekin bat egiten dira transakzioak irauten duen bitartean.
Eta gure lan-kargan, hori egia da. Baina arazo batzuk daude.
Arazoak saio bat diagnostikatu nahi duzunean hasten dira, zure sarrerako konexio guztiak tokikoak direlako. Denak loopback batekin etorri ziren eta, nolabait, zaila egiten da saioaren jarraipena egitea.
Noski aplikazio_izena_gehitu_ostalaria erabil dezakezu. Hau Bouncer aldean IP helbide bat gehitzeko aplikazio_izena da. Baina aplikazio_izena konexio gehigarri batek ezartzen du.
Grafiko honetan, non marra horia benetako eskaerak diren, eta non marra urdina datu-basera hegan egiten duten eskaerak diren. Eta desberdintasun hori, hain zuzen, aplikazio_izena instalatzea da, trazatzeko bakarrik beharrezkoa dena, baina ez da batere doakoa.
Horrez gain, Bouncer-en ezin duzu igerileku bat mugatu, hau da, datu-baseko konexio kopurua erabiltzaile zehatz bakoitzeko, datu-base zehatz bakoitzeko.
Zertara eramaten du horrek? C++-n idatzitako zerbitzu kargatu bat duzu eta, nonbait, datu-basearekin ezer ikaragarririk egiten ez duen nodo batean zerbitzu txiki bat, baina bere kontrolatzailea erotu egiten da. 20 konexio irekitzen ditu eta gainerako guztia itxarongo da. Zure kodea ere normala da.
Noski, Bouncer-entzako adabaki txiki bat idatzi genuen ezarpen hau gehitzen zuena, hau da, bezeroak igerilekura mugatuz.
Posible litzateke hau Postgres aldean egitea, hau da, datu-baseko rolak konexio kopuruaren arabera mugatzea.
Baina gero zerbitzariarekin konexiorik ez duzun ulertzeko gaitasuna galtzen duzu. PgBouncer-ek ez du konexio-errorerik botatzen, beti informazio bera itzultzen du. Eta ezin duzu ulertu: agian zure pasahitza aldatu egin da, agian datu-basea galdu berri da, agian zerbait gaizki dago. Baina ez dago diagnostikorik. Saio bat ezarri ezin bada, ez duzu jakingo zergatik ezin den ezarri.
Une jakin batean, aplikazioaren grafikoak begiratu eta aplikazioak ez duela funtzionatzen ikusten duzu.
Begiratu goian eta ikusi Bouncer hari bakarrekoa dela. Inflexio puntu bat da zerbitzuaren bizitzan. Urte eta erdian datu-basea eskalatzeko prestatzen ari zinela konturatzen zara, eta pooler eskalatu behar duzula.
PgBouncers gehiago behar ditugula ondorioztatu dugu.
Errebotea apur bat adabakia izan da.
Eta TCP ataka berrerabiliz hainbat Bouncer planteatu ahal izateko egin zuten. Eta sistema eragileak automatikoki transferitzen ditu sarrerako TCP konexioak haien artean round-robin erabiliz.
Hau gardena da bezeroentzat, hau da, Bouncer bat duzula dirudi, baina Bouncers exekutatzen ari direnen artean inaktiboen konexioak zatikatuta dituzu.
Eta une jakin batean ohartuko zara 3 Bouncer hauek bakoitzak bere muina %100ean jaten duela. Errebote dezente behar dituzu. Zergatik?
TLS duzulako. Enkriptatutako konexioa duzu. Eta Postgres-ek TLS-rekin eta TLS gabe erreferenteak egiten badituzu, enkriptatzea gaituta dagoenean ezarritako konexioen kopurua ia bi magnitude jaisten dela ikusiko duzu, TLS esku-emateak CPU baliabideak kontsumitzen dituelako.
Eta goiko aldean funtzio kriptografiko asko ikus ditzakezu sarrerako konexioen bolada bat dagoenean exekutatzen direnak. Gure nagusiek erabilgarritasun-eremu batetik bestera alda dezaketenez, sarrerako konexioen olatu bat nahiko ohikoa da. Hau da, arrazoiren batengatik primario zaharra ez zegoen erabilgarri, karga osoa beste datu-zentro batera bidali zen. Denak etorriko dira aldi berean TLSri agurtzera.
Eta TLS esku-emate kopuru handi batek ez du jada Bouncerri kaixo esan, baina eztarria estutuko du. Denbora-mugaren ondorioz, sarrerako konexioen uhina moteldu gabe geratu daiteke. Oinarrira berriro saiatzen bazara atzerapen esponentzial gabe, ez dira behin eta berriz etorriko olatu koherente batean.
Hona hemen %16ean 16 nukleo kargatzen dituzten 100 PgBouncers adibide bat.
PgBouncer kaskadara iritsi ginen. Hau da Bouncer-ekin gure kargan lor daitekeen konfigurazio onena. Gure kanpoko erreboteak TCP esku-ematerako erabiltzen dira, eta barneko erreboteak benetako bilketa egiteko erabiltzen dira, kanpoko konexioak gehiegi zatitu ez daitezen.
Konfigurazio honetan, berrabiarazi leun bat posible da. 18 Bouncer hauek guztiak banan-banan berrabia ditzakezu. Baina konfigurazio hori mantentzea nahiko zaila da. Sysadmins, DevOps eta zerbitzari honen arduradunak diren pertsonak ez dira oso pozik egongo antolaketa honekin.
Badirudi gure hobekuntza guztiak kode irekira sustatu daitezkeela, baina Bouncer-ek ez du oso ondo onartzen. Adibidez, hainbat PgBouncer ataka batean exekutatzeko gaitasuna duela hilabete konprometitu zen. Ezaugarri honekin tiraka eskaera bat egon zen duela zenbait urte.
Edo adibide bat gehiago. Postgres-en, abian dagoen eskaera bertan behera utzi dezakezu sekretua beste konexio batera bidaliz alferrikako autentifikaziorik gabe. Baina bezero batzuek TCP berrezartzea besterik ez dute bidaltzen, hau da, sareko konexioa hausten dute. Zer egingo du Bouncerrek? Ez du ezer egingo. Eskaera exekutatzen jarraituko du. Eskaera txikiekin datu-base bat sortu duten konexio ugari jaso badituzu, Bouncer-etik konexioa deskonektatzea ez da nahikoa izango; datu-basean exekutatzen ari diren eskaera horiek ere osatu behar dituzu.
Hau parkeatu egin da eta arazo hau oraindik ez da batu Bouncer-en upstream-en.
Hortaz, ondorioztatu genuen gure konexio-bilgailu propioa behar dugula, garatuko dena, adabakituko dena, arazoak azkar zuzendu ahal izateko eta, noski, hari anitzekoa izan behar duena.
Multithreading ezarri dugu zeregin nagusi gisa. Sarrerako TLS konexioen olatua ondo kudeatu behar dugu.
Horretarako, Machinarium izeneko liburutegi bereizi bat garatu behar izan dugu, sareko konexio baten makinen egoerak kode sekuentzial gisa deskribatzeko diseinatuta dagoena. libpq iturburu-kodeari erreparatzen badiozu, emaitza bat itzul diezazuketen dei konplexu batzuk ikusiko dituzu eta "Deitu geroago. Momentuz IO daukat oraingoz, baina IOa desagertzen denean karga bat izango dut prozesadoreanβ. Eta hau maila anitzeko eskema da. Sareko komunikazioa egoera-makina batek deskribatzen du normalean. Arau asko "Lehen N tamainako paketeen goiburua jaso banuen, orain N byteren zain nago", "SYNC pakete bat bidali badut, orain emaitza metadatuak dituen pakete baten zain nago". Emaitza kode nahiko zaila eta intuitiboa da, labirintoa lerro-eskaneatzera bihurtuko balitz bezala. Egoera-makina baten ordez, programatzaileak elkarrekintzaren bide nagusia deskribatzen du kode inperatibo arruntaren moduan. Besterik da ezinbesteko kode honetan exekuzio-sekuentzia eten behar den tokiak txertatu behar dituzula sareko datuen zain, exekuzio-testuingurua beste korutina batera pasatuz (hari berdea). Planteamendu hau labirintoan gehien espero den bidea segidan idazten dugunaren antzekoa da, eta gero adarrak gehitzen dizkiogula.
Ondorioz, TCP-k onartzen duen hari bat dugu eta round-robin-ek TPC konexioa langile askori pasatzen die.
Kasu honetan, bezero-konexio bakoitza prozesadore batean exekutatzen da beti. Eta horri esker, cachea errespetatzen duzu.
Horrez gain, pakete txikien bilduma pakete handi batean apur bat hobetu dugu sistemaren TCP pila arintzeko.
Horrez gain, transakzio-bilketa hobetu dugu, izan ere, Odyssey-k, konfiguratuta dagoenean, CANCEL eta ROLLBACK bidal ditzake sare-konexioaren hutsegite bat gertatuz gero, hau da, inor ez badago eskaera baten zain, Odyssey-k datu-baseari esango dio ez saiatzeko. baliabide preziatuak xahutu ditzakeen eskaera betetzea.
Eta ahal den guztietan, bezero berarekin konexioak mantentzen ditugu. Honek aplikazio_izena_gehitu_ostalari berriro instalatu beharrik ekiditen du. Hori posible bada, orduan ez ditugu diagnostikorako beharrezkoak diren parametroak berrezarri beharrik.
Yandex.Cloud-en interesen alde egiten dugu lan. Eta PostgreSQL kudeatua erabiltzen baduzu eta konexio-biltzaile bat instalatuta baduzu, erreplikazio logikoa sor dezakezu kanpora, hau da, utzi gaitzazu, nahi izanez gero, erreplikazio logikoa erabiliz. Bouncerrek ez du kanpoan erreplikazio logikoa askatuko.
Hau erreplikazio logikoa konfiguratzeko adibide bat da.
Horrez gain, kanpoko erreplikazio fisikorako laguntza dugu. Hodeian, noski, ezinezkoa da, orduan klusterrak bere buruari buruzko informazio gehiegi emango dizulako. Baina zure instalazioetan, Odyssey-ko konexio-bilgailuaren bidez erreplikazio fisikoa behar baduzu, hau posible da.
Odyssey-k PgBouncer-ekin jarraipen guztiz bateragarria du. Ia komando guztiak exekutatzen dituen kontsola bera dugu. Zerbait falta bada, bidali pull eskaera bat, edo gutxienez arazo bat GitHub-en, eta beharrezko komandoak osatuko ditugu. Baina dagoeneko badugu PgBouncer kontsolaren funtzionalitate nagusia.
Eta, noski, akatsak birbidaltzeko ditugu. Datu-baseak jakinarazitako errorea itzuliko dugu. Datu-basean zergatik ez zareten sartzen informazioa jasoko duzu, eta ez bakarrik bertan sartzen ez zarenari buruz.
Ezaugarri hau desgaituta dago PgBouncer-ekin %100eko bateragarritasuna behar baduzu. Bouncer-en modu berean joka dezakegu, seguru aldean egoteko.
diseinua
Odyssey iturburu kodeari buruzko hitz batzuk.
Adibidez, "Pausatu / Berrekin" komandoak daude. Normalean datu-basea eguneratzeko erabiltzen dira. Postgres eguneratu behar baduzu, orduan pausatu dezakezu konexio-bilgailuan, egin pg_upgrade, eta jarraitu berriro. Eta bezeroaren aldetik datu-basea moteltzen ari zela dirudi. Funtzionalitate hau komunitateko jendeak ekarri digu. Oraindik ez dago izoztuta, baina laster dena egongo da. (Dagoeneko izoztuta)
- dagoeneko izoztuta
Horrez gain, PgBouncer-en eginbide berrietako bat SCRAM autentifikaziorako laguntza da, Yandex.Cloud-en lan egiten ez duen pertsona batek ere ekarri diguna. Biak funtzionaltasun konplexuak eta garrantzitsuak dira.
Horregatik, Odyssey zertaz egina dagoen esan nahiko nuke, zuk ere orain kodetxo bat idatzi nahi baduzu.
Odyssey iturri-oinarria duzu, bi liburutegi nagusitan oinarritzen dena. Kiwi liburutegia Postgres mezuen protokoloaren inplementazioa da. Hau da, Postgres-en jatorrizko proto 3 frontend-ek eta back-end-ek truka ditzaketen mezu estandarrak dira. Kiwi liburutegian ezartzen dira.
Machinarium liburutegia haria inplementatzeko liburutegia da. Machinarium honen zati txiki bat muntaia hizkuntzan idatzita dago. Baina ez larritu, 15 lerro besterik ez daude.
Odisea arkitektura. Koroutinak exekutatzen ari diren makina nagusi bat dago. Makina honek sarrerako TCP konexioak onartu eta langileen artean banatzen ditu.
Hainbat bezeroren kudeatzaileak langile baten barruan lan egin dezake. Hari nagusiak kontsola eta crone zereginak prozesatzen ditu igerilekuan beharrezkoak ez diren konexioak ezabatzeko.
Odyssey Postgres test suite estandarra erabiliz probatzen da. Bouncer-en bidez instalazio-egiaztapena exekutatzen dugu eta Odyssey bidez, div nulua lortzen dugu. Bouncer-en eta Odyssey-n guztiz berdina gainditzen ez duten data-formatearekin lotutako hainbat proba daude.
Horrez gain, asko dira proba propioak dituzten gidariak. Eta haien probak Odisea probatzeko erabiltzen ditugu.
Horrez gain, gure kaskadako konfigurazioa dela eta, hainbat sorta probatu behar ditugu: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, Odyssey kaskadako zatiren batean amaituko balu, oraindik ere funtzionatzen duela ziurtatzeko. espero dugun bezala.
rake
Produkzioan Odyssey erabiltzen dugu. Eta ez litzateke bidezkoa izango dena funtzionatzen duela esango banu. Ez, hau da, bai, baina ez beti. Adibidez, ekoizpenean dena funtzionatu zuen, gero PostgreSQL Professional-eko gure lagunak etorri ziren eta esan zuten memoria-filtrazio bat genuela. Benetan ziren, zuzendu genituen. Baina sinplea zen.
Orduan aurkitu genuen konexio-biltzaileak sarrerako TLS konexioak eta irteerako TLS konexioak dituela. Eta konexioek bezero-ziurtagiriak eta zerbitzari-ziurtagiriak behar dituzte.
Bouncer eta Odyssey zerbitzariaren ziurtagiriak beren pcache-tik berrirakurtzen dira, baina bezeroen ziurtagiriak ez dira pcachetik berriro irakurri behar, gure Odyssey eskalagarriak ziurtagiri hau irakurtzeko sistemaren errendimenduan sartzen delako azken finean. Harritu egin zitzaigun honek, ez baitzuen denbora asko behar aurre egiteko. Hasieran linealki eskalatu zen, baina aldibereko 20 konexioren ostean arazo hau agertu zen.
Pluggable Authentication Method integratutako Lunux tresnak erabiliz autentifikatzeko gaitasuna da. PgBouncer-en modu horretan inplementatzen da, PAM-en erantzunaren zain egoteko aparteko hari bat dagoela eta PgBouncer-en hari nagusi bat dagoela uneko konexioa zerbitzatzen duena eta PAM harian bizitzeko eska diezaiekeen.
Ez dugu hau gauzatu arrazoi sinple batengatik. Hari asko ditugu. Zergatik behar dugu hau?
Azken finean, horrek arazoak sor ditzake PAM autentifikazioa eta PAM ez den autentifikazioa badituzu, PAM autentifikazioaren olatu handi batek PAM ez den autentifikazioa nabarmen atzeratu dezake. Hau konpondu ez dugun gauza horietako bat da. Baina konpondu nahi baduzu, hau egin dezakezu.
Beste arrasto bat izan zen sarrerako konexio guztiak onartzen dituen hari bat dugula. Ondoren, langileen biltegira eramaten dira, non TLS esku-ematea egingo den.
Azken finean, 20 sare-konexioko olatu koherentea baduzu, guztiak onartuko dira. Eta bezeroaren aldetik libpq denbora-muga jakinarazten hasiko da. Lehenespenez 000 segundokoa dela dirudi.
Guztiak datu-basean aldi berean sartu ezin badira, ezin izango dute datu-basean sartu, hori guztia berriro saiakuntza ez-esponentziala bidez estali daitekeelako.
PgBouncer-etik eskema hemen kopiatu genuela ondorioztatu genuen, onartzen ditugun TCP konexio kopurua mugatu dugulako.
Konexioak onartzen ari garela ikusten badugu, baina azkenean ez dutela eskua emateko astirik, ilaran jartzen ditugu PUZaren baliabideak xahutu ez ditzaten. Horrek aldibereko esku-eskubidea ez egitea dakar heldu diren konexio guztietan. Baina gutxienez norbait sartuko da datu-basean, nahiz eta karga nahiko astuna izan.
Ibilbide Orria
Zer ikusi nahiko zenuke etorkizunean Odisea-n? Zer gaude prest geure burua garatzeko eta zer espero dugu komunitatetik?
2019ko abuztuan.
Hona hemen Odyssey bide-orriak abuztuan:
- SCRAM eta PAM autentifikazioa nahi genuen.
- Irakurketa eskaerak erreserba moduan helarazi nahi izan ditugu.
- Lineako berrabiarazi nahi nuke.
- Eta zerbitzarian pausatzeko gaitasuna.
Bide orri honen erdia osatu da, eta ez guk. Eta hau ona da. Beraz, eztabaida dezagun geratzen dena eta gehi dezagun gehiago.
? Eskaerak exekutatu gabe airea berotuko duten erreplikak ditugu. Haiek behar ditugu hutsegite eta aldaketa emateko. Datu-zentroren batean arazoak izanez gero, lan erabilgarri batekin okupatu nahiko nuke. Ezin ditugulako prozesadore zentral berdinak konfiguratu, memoria bera modu ezberdinean, bestela erreplikazioak ez duelako funtzionatuko.
Printzipioz, Postgres-en, 10etik hasita, session_attrs zehaztea posible da konektatzean. Konexioan dauden datu-basearen ostalari guztiak zerrenda ditzakezu eta datu-basera zergatik zoazen esan: idatzi edo irakurri soilik. Eta gidariak berak hautatuko du gehien gustatzen zaion zerrendako lehen ostalaria, session_attrs-en baldintzak betetzen dituena.
Baina ikuspegi honen arazoa da ez duela erreplikazioaren atzerapena kontrolatzen. Baliteke zure zerbitzurako denbora onartezin batean atzean geratu den erreplika bat izatea. Erreplika batean irakurketa-kontsulten exekuzio oso-osorik gaitzeko, funtsean, Odyssey-k ez exekutatzeko gaitasuna onartu behar dugu irakurri ezin denean.
Odyssey-k datu-basera joan behar du noizean behin eta lehengoarekiko erreplika-distantzia eskatu. Eta muga-balioa iritsi bada, ez onartu eskaera berririk datu-basean, esan bezeroari konexioak berriro hasi behar dituela eta, agian, beste ostalari bat hautatu eskaerak egiteko. Horri esker, datu-baseak erreplikazioaren atzerapena azkar berreskuratuko du eta berriro itzultzeko eskaera batekin erantzuteko.
Zaila da ezarpenerako denbora-tarte bat ematea, kode irekia delako. Baina, espero dut, ez 2,5 urte PgBouncer-eko nire lankideek bezala. Hau da Odisea-n ikusi nahiko nukeen ezaugarria.
. Orain prestatutako adierazpen bat sor dezakezu bi modutan. Lehenik eta behin, SQL komandoa exekutatu dezakezu, hots, "prestatuta". SQL komando hau ulertzeko, Bouncer aldean dagoen SQL ulertzen ikasi behar dugu. Hau gehiegikeria bat izango litzateke, gehiegizkoa delako, analizatzaile osoa behar dugulako. Ezin ditugu SQL komando guztiak analizatu.
Baina proto3-n mezu-protokolo mailan adierazpen bat dago. Eta prestatutako adierazpena sortzen ari den informazioa forma egituratuan iristen den lekua da. Eta zerbitzari-konexio batzuetan bezeroak prestatutako adierazpenak sortzeko eskatu zuela uler genezake. Eta transakzioa itxita badago ere, zerbitzariaren eta bezeroaren arteko konexioa mantendu behar dugu.
Baina hemen elkarrizketan desadostasuna sortzen da, norbaitek esaten baitu bezeroak zer-nolako prestatutako adierazpenak sortu dituen ulertu behar duzula eta zerbitzari-konexioa zerbitzari-konexio hori sortu duten bezero guztien artean partekatu behar duzula, hau da, prestatutako adierazpen hori nork sortu duen.
Andres Freundek esan zuen bezero bat etortzen bazaizu, dagoeneko prestatutako adierazpena beste zerbitzari-konexio batean sortu duena, sortu ezazu harentzat. Baina oker samarra dirudi bezeroaren ordez datu-basean kontsultak egitea, baina datu-basearekin elkarreragiteko protokoloa idazten duen garatzailearen ikuspuntutik, komenigarria izango litzateke sare-konexio bat besterik ez balute. badago halako kontsulta prestatua.
Eta ezarri behar dugun ezaugarri bat gehiago. Orain PgBouncer-ekin bateragarria den monitorizazioa dugu. Kontsulten batez besteko exekuzio-denbora itzuli dezakegu. Baina batez besteko denbora ospitaleko batez besteko tenperatura da: batzuk hotzak dira, beste batzuk epelak - batez beste, denak osasuntsu daude. Ez da egia.
Baliabideak xahutzen ari diren eta monitorizazioa onargarriagoa egiten duten kontsulta motelak daudela adieraziko luketen pertzentiletarako laguntza ezarri behar dugu.
Garrantzitsuena 1.0 bertsioa nahi dudala da (1.1 bertsioa dagoeneko kaleratu da). Kontua da orain Odyssey 1.0rc bertsioan dagoela, hau da, kaleratzeko hautagaia. Eta zerrendatu ditudan arazo guztiak bertsio berdinarekin konpondu ziren, memoria-ihesarekin izan ezik.
Zer suposatuko du guretzat 1.0 bertsioak? Odyssey gure oinarrietara zabaltzen ari gara. Dagoeneko gure datu-baseetan exekutatzen ari da, baina segundoko 1 eskaeraren puntura iristen denean, esan dezakegu hau kaleratzeko bertsioa dela eta hau 000 dei daitekeen bertsioa dela.
Komunitateko hainbat lagunek 1.0 bertsioak pausa eta SCRAM sartzeko eskatu dute. Baina horrek esan nahi du hurrengo bertsioa produkziora atera beharko dugula, SCRAM ezta pausa oraindik ez direlako hil. Baina, ziurrenik, arazo hau nahiko azkar konponduko da.
Zure tira eskaeraren zain nago. Bouncer-ekin zer arazo dituzun ere entzun nahiko nuke. Eztabaida ditzagun. Beharbada behar dituzun funtzio batzuk ezar ditzakegu.
Hau amaitzen da nire zatia, entzutea gustatuko litzaidake. Eskerrik asko!
Zure galderak
Nire aplikazio_izena ezartzen badut, zuzen birbidaliko al da, Odyssey-ko transakzioen bilketan barne?
Odisea ala Errebotea?
Odisean. Bouncer-en botatzen da.
Multzo bat egingo dugu.
Eta nire benetako konexioa beste konexio batzuetan salto egiten badu, transmitituko al da?
Zerrendan ageri diren parametro guztien multzoa egingo dugu. Ezin dut esan aplikazio_izena zerrenda honetan dagoen. Uste dut han ikusi nuela. Parametro berdinak ezarriko ditugu. Eskaera batekin, multzoak abiaraztean bezeroak instalatutako guztia egingo du.
Eskerrik asko, Andrey, erreportajeagatik! Erreportaje ona! Pozten naiz Odyssey minuturo gero eta azkarrago garatzen ari delako. Horrela jarraitu nahi dut. Dagoeneko eskatu dizugu datu-iturburu anitzeko konexioa izateko, Odyssey-k datu-base desberdinetara aldi berean konektatu ahal izateko, hau da, esklabo nagusi batera, eta, ondoren, automatikoki maisu berri batera konektatu hutsegitearen ondoren.
Bai, badirudi eztabaida hau gogoratzen dudala. Orain hainbat biltegiratze daude. Baina ez dago haien artean aldaketarik. Gure aldetik, zerbitzariari oraindik bizirik dagoela eta hutsegite bat gertatu dela ulertu behar dugu, pg_recovery deituko duena. Ulertzeko modu estandar bat dut ez garela maisuarengana etorri. Eta akatsetatik nolabait ulertu behar dugu edo zer? Hau da, ideia interesgarria da, eztabaidatzen ari da. Idatzi iruzkin gehiago. C ezagutzen duten langileak badituzu, ezin hobea da.
Errepliketan eskalatzearen gaia ere interesgarria da guretzat, erreplikatutako klusterren adopzioa aplikazioen garatzaileentzat ahalik eta errazena egin nahi dugulako. Baina hemen komentario gehiago nahi nituzke, hau da, zehazki nola egin, nola egin ondo.
Galdera erreplikei buruzkoa ere bada. Bihurtzen da maisu bat eta hainbat erreplika dituzula. Eta argi dago erreplikara maisuarengana baino gutxiago joaten direla konexioetarako, ezberdintasunak izan ditzaketelako. Esan duzu datuen aldea zure negozioa aseko ez duela eta ez zarela bertara joango errepikatu arte. Aldi berean, denbora luzez bertara joan ez bazara, eta gero joaten hasi bazara, beharrezkoak diren datuak ez dira berehala egongo. Hau da, maisuarengana etengabe joaten bagara, orduan hango cachea berotzen da, baina erreplikan cachea pixka bat atzeratzen da.
Bai egia da. Pcache-ak ez ditu nahi dituzun datu-blokeak izango, benetako cache-ak ez du nahi dituzun taulei buruzko informaziorik izango, planek ez dute analizatutako kontsultarik izango, ez da ezer egongo.
Eta nolabaiteko kluster bat duzunean eta bertan erreplika berri bat gehitzen duzunean, abiarazten den bitartean, dena gaizki dago bertan, hau da, bere cachea handitzen du.
Ideia hartu nuen. Planteamendu zuzena erreplikan lehenengo kontsulten ehuneko txiki bat exekutatzea litzateke, eta horrek cachea berotuko luke. Gutxi gorabehera, baldintza bat dugu maisuaren atzetik 10 segundo baino gehiago egon behar dugula. Eta baldintza hau ez dago olatu batean sartzen, bezero batzuentzat leunki baizik.
Bai, pisua handitu.
Hau ideia ona da. Baina lehenik itxiera hau ezarri behar dugu. Lehenik eta behin itzali behar dugu, eta gero pentsatuko dugu nola piztu. Ezaugarri bikaina da leunki gaitzeko.
Nginx-ek aukera hau du slowly start zerbitzarirako kluster batean. Eta pixkanaka karga handitzen du.
Bai, ideia bikaina, horretara iristen garenean saiatuko gara.
Iturria: www.habr.com