In sy verslag sal Andrey Borodin jou vertel hoe hulle die ervaring van die skaal van PgBouncer in ag geneem het by die ontwerp van die verbindingpooler , soos hulle dit in produksie uitgerol het. Daarbenewens sal ons bespreek watter funksies van die trekker ons graag in nuwe weergawes wil sien: dit is vir ons belangrik om nie net aan ons behoeftes te voldoen nie, maar om die gebruikersgemeenskap te ontwikkel .
Video:
Hi almal! My naam is Andrew.
By Yandex ontwikkel ek oopbrondatabasisse. En vandag het ons 'n onderwerp oor konneksiepoelverbindings.
As jy weet hoe om verbindingpooler in Russies te bel, vertel my dan. Ek wil regtig 'n goeie tegniese term vind wat in die tegniese literatuur gevestig moet word.
Die onderwerp is nogal ingewikkeld, want in baie databasisse is die konneksiepoeler ingebou en jy hoef nie eers daarvan te weet nie. Natuurlik is daar oral 'n paar instellings, maar in Postgres werk dit nie so nie. En in parallel (by HighLoad++ 2019) is daar 'n verslag deur Nikolai Samokhvalov oor die opstel van navrae in Postgres. En soos ek dit verstaan, het mense hierheen gekom wat reeds hul navrae perfek gekonfigureer het, en dit is mense wat gekonfronteer word met meer seldsame stelselprobleme wat verband hou met die netwerk en hulpbronbenutting. En op sommige plekke kan dit nogal moeilik wees in die sin dat die probleme nie voor die hand liggend is nie.
Yandex het Postgres. Baie Yandex-dienste woon in Yandex.Cloud. En ons het verskeie petagrepe data wat ten minste 'n miljoen versoeke per sekonde in Postgres genereer.
En ons bied 'n redelike standaardgroepering vir alle dienste - dit is die hoof primêre nodus van die nodus, die gewone twee replikas (sinchronies en asinchronies), rugsteun, skaal van leesversoeke op die replika.
Elke cluster node is Postgres, waarop, benewens Postgres en moniteringstelsels, ook 'n verbindingpooler geïnstalleer is. Connection pooler word gebruik vir omheining en vir sy hoofdoel.
Wat is die hoofdoel van verbindingpoeler?
Postgres neem 'n prosesmodel aan wanneer daar met 'n databasis gewerk word. Dit beteken dat een verbinding een proses is, een Postgres-agterkant. En in hierdie backend is daar baie verskillende kas, wat redelik duur is om anders te maak vir verskillende verbindings.
Boonop het Postgres-kode 'n skikking genaamd procArray. Dit bevat basiese data oor netwerkverbindings. En byna alle procArray-verwerkingsalgoritmes het lineêre kompleksiteit; hulle loop oor die hele reeks netwerkverbindings. Dit is 'n redelik vinnige siklus, maar met meer inkomende netwerkverbindings word dinge 'n bietjie duurder. En wanneer dinge 'n bietjie duurder word, kan jy uiteindelik 'n baie hoë prys betaal vir baie netwerkverbindings.
Daar is 3 moontlike benaderings:
- Aan die toepassingskant.
- Aan die databasis kant.
- En tussen, dit wil sê, allerhande kombinasies.
Ongelukkig is die ingeboude swembader tans onder ontwikkeling. Ons vriende by PostgreSQL Professional doen dit meestal. Wanneer dit sal verskyn, is moeilik om te voorspel. En om die waarheid te sê, ons het twee oplossings vir die argitek om van te kies. Dit is toepassingskantpoel en instaanpoel.
Toepassing-kant swembad is die maklikste manier. En byna alle kliëntbestuurders bied jou 'n manier: bied miljoene van jou verbindings in kode aan as 'n paar dosyn verbindings met die databasis.
Die probleem wat ontstaan is dat jy op 'n sekere punt die backend wil skaal, jy dit op baie virtuele masjiene wil ontplooi.
Dan besef jy dat jy nog verskeie beskikbaarheidsones het, verskeie datasentrums. En die kliëntkant-poelbenadering lei tot groot getalle. Grotes is ongeveer 10 000 verbindings. Dit is die rand wat normaal kan werk.
As ons praat van proxy poolers, dan is daar twee poolers wat baie dinge kan doen. Hulle is nie net poelers nie. Hulle is poolers + meer cool funksionaliteit. Hierdie и .
Maar ongelukkig het nie almal hierdie bykomende funksionaliteit nodig nie. En dit lei tot die feit dat poelers slegs sessiepooling ondersteun, dit wil sê een inkomende kliënt, een uitgaande kliënt na die databasis.
Dit is nie baie geskik vir ons doeleindes nie, daarom gebruik ons PgBouncer, wat transaksiepoel implementeer, dit wil sê bedienerverbindings word slegs vir die duur van die transaksie met kliëntverbindings gepas.
En in ons werklading is dit waar. Maar daar is 'n paar probleme.
Die probleme begin wanneer jy 'n sessie wil diagnoseer, want al jou inkomende verbindings is plaaslik. Almal het met 'n terugloop gekom en op een of ander manier word dit moeilik om die sessie op te spoor.
Natuurlik kan jy application_name_add_host gebruik. Dit is 'n manier aan die Bouncer-kant om 'n IP-adres by application_name te voeg. Maar application_name word gestel deur 'n bykomende verbinding.
Op hierdie grafiek, waar die geel lyn werklike versoeke is, en waar die blou lyn versoeke is wat in die databasis invlieg. En hierdie verskil is juis die installering van application_name, wat slegs nodig is vir opsporing, maar dit is glad nie gratis nie.
Daarbenewens kan jy in Bouncer nie een poel beperk nie, dit wil sê die aantal databasisverbindings per spesifieke gebruiker, per spesifieke databasis.
Waartoe lei dit? Jy het 'n gelaaide diens wat in C++ geskryf is en iewers naby 'n klein diens op 'n nodus wat niks vreesliks met die databasis doen nie, maar die bestuurder daarvan word mal. Dit maak 20 000 verbindings oop en alles anders sal wag. Selfs jou kode is normaal.
Ons het natuurlik 'n klein pleister vir Bouncer geskryf wat hierdie instelling bygevoeg het, dit wil sê om kliënte tot die swembad te beperk.
Dit sou moontlik wees om dit aan die Postgres-kant te doen, dit wil sê, die rolle in die databasis te beperk deur die aantal verbindings.
Maar dan verloor jy die vermoë om te verstaan hoekom jy geen verbindings met die bediener het nie. PgBouncer gooi nie 'n verbindingsfout nie, dit gee altyd dieselfde inligting terug. En jy kan nie verstaan nie: dalk het jou wagwoord verander, dalk het die databasis net verlore geraak, dalk is iets fout. Maar daar is geen diagnose nie. As 'n sessie nie gevestig kan word nie, sal jy nie weet hoekom dit nie gevestig kan word nie.
Op 'n sekere punt kyk jy na die toepassingsgrafieke en sien dat die toepassing nie werk nie.
Kyk na die bokant en sien dat Bouncer enkeldraad is. Dit is 'n keerpunt in die lewe van die diens. Jy besef dat jy voorberei het om die databasis oor 'n jaar en 'n half te skaal, en jy moet die pooler skaal.
Ons het tot die gevolgtrekking gekom dat ons meer PgBouncers nodig het.
Bouncer is 'n bietjie gelap.
En hulle het dit so gemaak dat verskeie Bouncers opgewek kon word deur die TCP-poort te hergebruik. En die bedryfstelsel dra outomaties inkomende TCP-verbindings tussen hulle oor met behulp van round-robin.
Dit is deursigtig vir kliënte, wat beteken dat dit lyk of jy een Bouncer het, maar jy het fragmentasie van ledige verbindings tussen lopende Bouncers.
En op 'n sekere oomblik sal jy dalk agterkom dat hierdie 3 Bouncers elkeen hul kern met 100% opvreet. Jy het 'n hele paar Bouncers nodig. Hoekom?
Omdat jy TLS het. Jy het 'n geënkripteerde verbinding. En as jy Postgres met en sonder TLS meet, sal jy vind dat die aantal gevestigde verbindings met byna twee ordes van grootte daal met enkripsie aangeskakel, omdat die TLS-handdruk SVE-hulpbronne verbruik.
En aan die bokant kan jy 'n hele paar kriptografiese funksies sien wat uitgevoer word wanneer daar 'n golf van inkomende verbindings is. Aangesien ons primêre tussen beskikbaarheidsones kan wissel, is 'n golf van inkomende verbindings 'n redelik tipiese situasie. Dit wil sê, om een of ander rede was die ou primêre nie beskikbaar nie, die hele vrag is na 'n ander datasentrum gestuur. Hulle sal almal terselfdertyd vir TLS kom hallo sê.
En 'n groot aantal TLS-handdruk sê dalk nie meer vir Bouncer hallo nie, maar sal sy keel toedruk. As gevolg van die uitteltyd kan die golf van inkomende verbindings ongedemp word. As jy weer na die basis probeer sonder eksponensiële terugslag, sal hulle nie weer en weer in 'n koherente golf kom nie.
Hier is 'n voorbeeld van 16 PgBouncers wat 16 kerns teen 100% laai.
Ons het by die waterval PgBouncer gekom. Dit is die beste konfigurasie wat op ons vrag met Bouncer bereik kan word. Ons eksterne Bouncers word gebruik vir TCP-handdruk, en interne Bouncers word gebruik vir werklike poel, om nie eksterne verbindings te veel te fragmenteer nie.
In hierdie konfigurasie is 'n gladde herbegin moontlik. Jy kan al hierdie 18 Bouncers een vir een herbegin. Maar om so 'n konfigurasie te handhaaf is nogal moeilik. Sysadmins, DevOps, en mense wat eintlik verantwoordelik is vir hierdie bediener sal nie baie gelukkig wees met hierdie reëling nie.
Dit wil voorkom asof al ons verbeterings na oopbron bevorder kan word, maar Bouncer word nie baie goed ondersteun nie. Byvoorbeeld, die vermoë om verskeie PgBouncers op een poort te laat loop, is 'n maand gelede gepleeg. Daar was 'n trekversoek met hierdie kenmerk etlike jare gelede.
Of nog een voorbeeld. In Postgres kan u 'n versoek wat aan die gang is, kanselleer deur die geheim na 'n ander verbinding te stuur sonder onnodige verifikasie. Maar sommige kliënte stuur eenvoudig 'n TCP-terugstelling, dit wil sê hulle verbreek die netwerkverbinding. Wat sal Bouncer doen? Hy sal niks doen nie. Dit sal voortgaan om die versoek uit te voer. As jy 'n groot aantal verbindings ontvang het wat 'n databasis met klein versoeke geskep het, dan sal dit nie genoeg wees om die verbinding van Bouncer te ontkoppel nie; jy moet ook die versoeke wat in die databasis loop, voltooi.
Dit is reggemaak en hierdie probleem is nog nie in Bouncer se stroomop saamgevoeg nie.
En so het ons tot die gevolgtrekking gekom dat ons ons eie konneksiepoeler nodig het, wat ontwikkel, gelap sal word, waarin probleme vinnig reggestel kan word en wat natuurlik multi-threaded moet wees.
Ons stel multithreading as die hooftaak. Ons moet die golf van inkomende TLS-verbindings goed kan hanteer.
Om dit te doen, moes ons 'n aparte biblioteek genaamd Machinarium ontwikkel, wat ontwerp is om die masjientoestande van 'n netwerkverbinding as opeenvolgende kode te beskryf. As jy na die libpq-bronkode kyk, sal jy 'n paar redelik komplekse oproepe sien wat vir jou 'n resultaat kan gee en sê: "Bel my later. Op die oomblik het ek IO vir nou, maar wanneer die IO weggaan, sal ek 'n las op die verwerker hê.” En dit is 'n multi-vlak skema. Netwerkkommunikasie word gewoonlik deur 'n staatsmasjien beskryf. Baie reëls soos "As ek voorheen 'n pakkieopskrif van grootte N ontvang het, wag ek nou vir N grepe," "As ek 'n SYNC-pakkie gestuur het, wag ek nou vir 'n pakkie met resultaatmetadata." Die resultaat is 'n taamlik moeilike, teen-intuïtiewe kode, asof die doolhof na lynskandering omgeskakel is. Ons het dit so gemaak dat die programmeerder in plaas van 'n staatsmasjien die hoofweg van interaksie in die vorm van gewone imperatiewe kode beskryf. Dit is net dat jy in hierdie noodsaaklike kode plekke moet invoeg waar die uitvoeringsvolgorde onderbreek moet word deur te wag vir data van die netwerk, en die uitvoeringskonteks na 'n ander koroutine (groen draad) oor te dra. Hierdie benadering is soortgelyk aan die feit dat ons die mees verwagte pad in die doolhof in 'n ry neerskryf, en dan takke daarby voeg.
As gevolg hiervan het ons een draad wat TCP aanvaar en round-robin gee die TPC-verbinding aan baie werkers deur.
In hierdie geval loop elke kliëntverbinding altyd op een verwerker. En dit laat jou toe om dit kasvriendelik te maak.
En daarbenewens het ons die versameling van klein pakkies effens verbeter in een groot pakkie om die stelsel TCP-stapel te verlig.
Daarbenewens het ons transaksionele poeling verbeter in die sin dat Odyssey, wanneer dit gekonfigureer is, KANSELLEER en TERUG kan stuur in die geval van 'n netwerkverbindingsfout, dit wil sê as niemand wag vir 'n versoek nie, sal Odyssey die databasis vertel om nie te probeer om voldoen aan die versoek wat kosbare hulpbronne kan vermors.
En waar moontlik, hou ons verbindings met dieselfde kliënt. Dit voorkom dat u application_name_add_host moet herinstalleer. As dit moontlik is, hoef ons nie die parameters wat nodig is vir diagnostiek bykomend te herstel nie.
Ons werk in die belang van Yandex.Cloud. En as jy bestuurde PostgreSQL gebruik en 'n verbindingpooler geïnstalleer het, kan jy logiese replikasie na buite skep, dit wil sê, los ons, as jy wil, met behulp van logiese replikasie. Bouncer sal nie die logiese replikasievloei buite vrystel nie.
Dit is 'n voorbeeld van die opstel van logiese replikasie.
Daarbenewens het ons ondersteuning vir fisiese replikasie na buite. In die Wolk is dit natuurlik onmoontlik, want dan sal die cluster jou te veel inligting oor homself gee. Maar in u installasies, as u fisiese replikasie benodig deur die verbindingpooler in Odyssey, is dit moontlik.
Odyssey het ten volle versoenbare monitering met PgBouncer. Ons het dieselfde konsole wat amper almal dieselfde opdragte uitvoer. As iets ontbreek, stuur 'n trekversoek, of ten minste 'n probleem op GitHub, en ons sal die nodige opdragte voltooi. Maar ons het reeds die hooffunksie van die PgBouncer-konsole.
En natuurlik het ons foutaanstuur. Ons sal die fout terugstuur wat deur die databasis gerapporteer is. Jy sal inligting ontvang oor hoekom jy nie by die databasis ingesluit is nie, en nie net dat jy nie daarby ingesluit is nie.
Hierdie kenmerk is gedeaktiveer as jy 100% versoenbaarheid met PgBouncer benodig. Ons kan op dieselfde manier as Bouncer optree, net om aan die veilige kant te wees.
ontwerp
'n Paar woorde oor die Odyssey-bronkode.
Byvoorbeeld, daar is "Pause / Hervat" opdragte. Hulle word gewoonlik gebruik om die databasis op te dateer. As jy Postgres moet opdateer, kan jy dit onderbreek in die verbindingpooler, pg_upgrade doen en dan hervat. En van die kliënt se kant af sal dit lyk asof die databasis net stadiger word. Hierdie funksionaliteit is deur mense uit die gemeenskap aan ons gebring. Sy is nog nie gevries nie, maar binnekort sal alles wees. (Reeds gevries)
- reeds gevries
Boonop is een van die nuwe kenmerke in PgBouncer ondersteuning vir SCRAM Authentication, wat ook aan ons gebring is deur 'n persoon wat nie in Yandex.Cloud werk nie. Albei is komplekse funksionaliteit en belangrik.
Daarom wil ek jou graag vertel waaruit Odyssey gemaak is, ingeval jy ook nou 'n bietjie kode wil skryf.
Jy het die Odyssey-bronbasis, wat staatmaak op twee hoofbiblioteke. Die Kiwi-biblioteek is 'n implementering van die Postgres-boodskapprotokol. Dit wil sê, inheemse proto 3 van Postgres is standaardboodskappe wat front-ends en back-ends kan uitruil. Hulle word in die Kiwi-biblioteek geïmplementeer.
Die Machinarium-biblioteek is 'n draadimplementeringsbiblioteek. 'n Klein fragment van hierdie Machinarium is in samestellende taal geskryf. Maar moenie bekommerd wees nie, daar is net 15 reëls.
Odyssey argitektuur. Daar is 'n hoofmasjien waarop koroutines loop. Hierdie masjien implementeer die aanvaarding van inkomende TCP-verbindings en versprei dit onder werkers.
'n Hanteerder vir verskeie kliënte kan binne een werker werk. Die hoofdraad loop ook die konsole en die verwerking van crone-take om verbindings uit te vee wat nie meer in die swembad benodig word nie.
Odyssey word getoets met die standaard Postgres-toetssuite. Ons hardloop net install-check deur Bouncer en deur Odyssey kry ons 'n nul div. Daar is verskeie toetse wat verband hou met datumformatering wat nie presies dieselfde in Bouncer en in Odyssey slaag nie.
Daarbenewens is daar baie bestuurders wat hul eie toetse het. En ons gebruik hul toetse om die Odyssey te toets.
Verder, as gevolg van ons kaskade-konfigurasie, moet ons verskeie bundels toets: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey om seker te wees dat as Odyssey in enige van die dele in die kaskade beland het, dit ook steeds werk soos ons verwag.
Hark
Ons gebruik Odyssey in produksie. En dit sal nie regverdig wees as ek sê dat alles net werk nie. Nee, dit wil sê, ja, maar nie altyd nie. Byvoorbeeld, in produksie het alles net gewerk, toe kom ons vriende van PostgreSQL Professional en sê ons het 'n geheuelek. Hulle was regtig, ons het hulle reggestel. Maar dit was eenvoudig.
Toe het ons ontdek dat die verbindingpooler inkomende TLS-verbindings en uitgaande TLS-verbindings het. En verbindings vereis kliëntsertifikate en bedienersertifikate.
Bouncer- en Odyssey-bedienersertifikate word herlees deur hul pcache, maar kliëntsertifikate hoef nie van pcache af hergelees te word nie, want ons skaalbare Odyssey loop uiteindelik in die stelselprestasie van die lees van hierdie sertifikaat in. Dit was vir ons 'n verrassing, want dit het hom nie lank geneem om teë te staan nie. Aanvanklik het dit lineêr geskaal, maar na 20 000 inkomende gelyktydige verbindings het hierdie probleem homself gewys.
Pluggable Authentication Method is die vermoë om te verifieer met behulp van ingeboude Lunux-nutsgoed. In PgBouncer is dit so geïmplementeer dat daar 'n aparte draad is om te wag vir 'n antwoord van PAM en daar is 'n hoof PgBouncer-draad wat die huidige verbinding bedien en hulle kan vra om in die PAM-draad te woon.
Ons het dit om een eenvoudige rede nie geïmplementeer nie. Ons het baie drade. Hoekom het ons dit nodig?
Dit kan uiteindelik probleme skep deurdat as jy PAM-verifikasie en nie-PAM-verifikasie het, 'n groot golf van PAM-verifikasie die nie-PAM-verifikasie aansienlik kan vertraag. Dit is een van daardie dinge wat ons nie reggemaak het nie. Maar as jy dit wil regmaak, kan jy dit doen.
Nog 'n hark was dat ons een draad het wat alle inkomende verbindings aanvaar. En dan word hulle na die werkerspoel oorgeplaas, waar die TLS-handdruk sal plaasvind.
Bottom line, as jy 'n samehangende golf van 20 000 netwerkverbindings het, sal hulle almal aanvaar word. En aan die kliëntkant sal libpq begin om uitteltyd te rapporteer. By verstek blyk dit 3 sekondes te wees.
As hulle almal nie die databasis op dieselfde tyd kan betree nie, kan hulle nie die databasis binnegaan nie, want dit alles kan gedek word deur nie-eksponensiële herprobering.
Ons het tot die gevolgtrekking gekom dat ons die skema van PgBouncer hierheen gekopieer het met die feit dat ons die aantal TCP-verbindings wat ons aanvaar, beperk.
As ons sien dat ons verbindings aanvaar, maar hulle het uiteindelik nie tyd om te handdruk nie, plaas ons hulle in 'n tou sodat hulle nie SVE-hulpbronne mors nie. Dit lei daartoe dat 'n gelyktydige handdruk nie uitgevoer mag word vir alle verbindings wat aangekom het nie. Maar ten minste sal iemand die databasis betree, selfs al is die vrag nogal swaar.
Padkaart
Wat sal jy graag in die toekoms in Odyssey wil sien? Wat is ons gereed om onsself te ontwikkel en wat verwag ons van die gemeenskap?
Vanaf Augustus 2019.
Dit is hoe die Odyssey-padkaart in Augustus gelyk het:
- Ons wou SCRAM- en PAM-verifikasie hê.
- Ons wou leesversoeke na bystand deurstuur.
- Ek wil graag 'n aanlyn herbegin hê.
- En die vermoë om op die bediener te onderbreek.
Die helfte van hierdie padkaart is voltooi, en nie deur ons nie. En dit is goed. Kom ons bespreek dus wat oorbly en voeg meer by.
? Ons het replikas wat bloot die lug sal verhit sonder om versoeke uit te voer. Ons het hulle nodig om oorskakeling en oorskakeling te verskaf. In die geval van probleme in een van die datasentrums, wil ek dit graag met nuttige werk besig hou. Omdat ons nie dieselfde sentrale verwerkers, dieselfde geheue anders kan konfigureer nie, want anders sal replikasie nie werk nie.
In beginsel, in Postgres, vanaf 10, is dit moontlik om session_attrs te spesifiseer wanneer u verbind. Jy kan al die databasisgashere in die verbinding lys en sê hoekom jy na die databasis gaan: skryf of lees net. En die bestuurder sal self die eerste gasheer in die lys kies waarvan hy die beste hou, wat aan die vereistes van session_attrs voldoen.
Maar die probleem met hierdie benadering is dat dit nie die replikasievertraging beheer nie. Jy het dalk een of ander replika wat vir 'n onaanvaarbare tyd vir jou diens agtergebly het. Om volledige uitvoering van leesnavrae op 'n replika moontlik te maak, moet ons in wese Odyssey se vermoë ondersteun om nie te hardloop wanneer dit nie gelees kan word nie.
Odyssey moet van tyd tot tyd na die databasis gaan en vra vir die replikasieafstand vanaf die primêre. En as dit die limietwaarde bereik het, moenie nuwe versoeke in die databasis toelaat nie, vertel die kliënt dat dit weer verbindings moet begin en moontlik 'n ander gasheer moet kies om versoeke uit te voer. Dit sal die databasis in staat stel om die replikasievertraging vinnig te herstel en weer terug te keer om met 'n versoek te reageer.
Dit is moeilik om 'n tydraamwerk vir implementering te gee, want dit is oopbron. Maar ek hoop nie 2,5 jaar soos my kollegas van PgBouncer nie. Dit is die kenmerk wat ek graag in die Odyssey wil sien.
. Nou kan jy 'n voorbereide verklaring op twee maniere skep. Eerstens kan jy die SQL-opdrag uitvoer, naamlik "voorbereid". Om hierdie SQL-opdrag te verstaan, moet ons leer om die SQL aan die Bouncer-kant te verstaan. Dit sal 'n oordrewe wees, want dit is oordrewe, aangesien ons die hele ontleder nodig het. Ons kan nie elke SQL-opdrag ontleed nie.
Maar daar is 'n voorbereide verklaring op die boodskapprotokolvlak op proto3. En dit is die plek wanneer die inligting dat 'n voorbereide verklaring geskep word, in 'n gestruktureerde vorm kom. En ons kan die begrip ondersteun dat die kliënt op een of ander bedienerverbinding gevra het om voorbereide stellings te maak. En selfs al is die transaksie gesluit, moet ons steeds verbinding tussen die bediener en die kliënt behou.
Maar hier ontstaan 'n teenstrydigheid in die dialoog, want iemand sê dat jy moet verstaan watter soort voorbereide stellings die kliënt geskep het en die bedienerverbinding deel tussen alle kliënte wat hierdie bedienerverbinding geskep het, dit wil sê wie so 'n voorbereide stelling geskep het.
Andres Freund het gesê dat as 'n kliënt na jou toe kom wat reeds so 'n voorbereide verklaring in 'n ander bedienerverbinding geskep het, skep dit dan vir hom. Maar dit lyk 'n bietjie verkeerd om navrae in die databasis uit te voer in plaas van die kliënt, maar vanuit die oogpunt van die ontwikkelaar wat die protokol vir interaksie met die databasis skryf, sal dit gerieflik wees as hy bloot 'n netwerkverbinding kry waarin daar is so 'n voorbereide navraag.
En nog een kenmerk wat ons moet implementeer. Ons het nou monitering wat versoenbaar is met PgBouncer. Ons kan die gemiddelde navraaguitvoertyd terugstuur. Maar die gemiddelde tyd is die gemiddelde temperatuur in die hospitaal: sommige is koud, sommige is warm - gemiddeld is almal gesond. Dis nie waar nie.
Ons moet ondersteuning vir persentiele implementeer, wat sou aandui dat daar stadige navrae is wat hulpbronne mors en monitering meer aanvaarbaar sal maak.
Die belangrikste ding is dat ek weergawe 1.0 wil hê (weergawe 1.1 is reeds vrygestel). Die feit is dat Odyssey nou in weergawe 1.0rc is, dit wil sê vrystellingskandidaat. En al die probleme wat ek gelys het, is reggestel met presies dieselfde weergawe, behalwe vir die geheuelek.
Wat sal weergawe 1.0 vir ons beteken? Ons is besig om Odyssey na ons basisse uit te rol. Dit loop reeds op ons databasisse, maar wanneer dit die punt van 1 000 000 versoeke per sekonde bereik, dan kan ons sê dat dit die vrystelling weergawe is en dit is 'n weergawe wat 1.0 genoem kan word.
Verskeie mense in die gemeenskap het gevra dat weergawe 1.0 pouse en SCRAM insluit. Maar dit sal beteken dat ons die volgende weergawe na produksie sal moet uitrol, want nóg SCRAM nóg pouse is nog doodgemaak. Maar waarskynlik sal hierdie probleem redelik vinnig opgelos word.
Ek wag vir jou trekversoek. Ek wil ook graag hoor watter probleme jy met Bouncer het. Kom ons bespreek hulle. Miskien kan ons 'n paar funksies implementeer wat jy nodig het.
Dit is die einde van my deel, ek wil graag na jou luister. Dankie!
vrae
As ek my eie application_name stel, sal dit korrek aangestuur word, insluitend in transaksiepoel in Odyssey?
Odyssey of Bouncer?
In Odyssey. In Bouncer word dit gegooi.
Ons sal 'n stel maak.
En as my regte verbinding op ander verbindings spring, sal dit oorgedra word?
Ons sal 'n stel maak van alle parameters wat in die lys gelys is. Ek kan nie sê of application_name in hierdie lys is nie. Ek dink ek het hom daar gesien. Ons sal almal dieselfde parameters stel. Met een versoek sal die stel alles doen wat deur die kliënt tydens die opstart geïnstalleer is.
Dankie, Andrey, vir die verslag! Goeie verslag! Ek is bly dat Odyssey elke minuut vinniger en vinniger ontwikkel. Ek wil so voortgaan. Ons het jou reeds gevra om 'n multidatabronverbinding te hê sodat Odyssey gelyktydig aan verskillende databasisse kan koppel, dit wil sê 'n meesterslaaf, en dan outomaties aan 'n nuwe meester koppel na failover.
Ja, dit lyk asof ek hierdie bespreking onthou. Nou is daar verskeie stoorplekke. Maar daar is geen wisseling tussen hulle nie. Aan ons kant moet ons die bediener vra dat dit nog lewendig is en verstaan dat 'n failover plaasgevind het, wie pg_recovery sal bel. Ek het 'n standaard manier om te verstaan dat ons nie na die meester gekom het nie. En moet ons op een of ander manier uit die foute verstaan of wat? Dit wil sê, die idee is interessant, dit word bespreek. Skryf meer kommentaar. As jy werkers het wat C ken, dan is dit wonderlik.
Die kwessie van skaal oor replikas is ook vir ons van belang, want ons wil die aanvaarding van gerepliseerde clusters so eenvoudig moontlik maak vir toepassingsontwikkelaars. Maar hier sal ek graag meer kommentaar wil hê, maw presies hoe om dit te doen, hoe om dit goed te doen.
Die vraag gaan ook oor replikas. Dit blyk dat jy 'n meester en verskeie replikas het. En dit is duidelik dat hulle minder gereeld na die replika gaan as na die meester vir verbindings, want hulle kan verskille hê. Jy het gesê dat die verskil in die data sodanig kan wees dat dit nie jou besigheid sal bevredig nie en jy sal nie daarheen gaan voordat dit gerepliseer is nie. Terselfdertyd, as jy vir 'n lang tyd nie daarheen gegaan het nie, en dan begin gaan het, dan sal die nodige data nie onmiddellik beskikbaar wees nie. Dit wil sê, as ons voortdurend na die meester gaan, word die kas daar opgewarm, maar in die replika bly die kas 'n bietjie agter.
Ja, dit is waar. Die pcache sal nie die datablokke hê wat jy wil hê nie, die regte kas sal nie inligting hê oor die tabelle wat jy wil hê nie, die planne sal nie ontleed navrae hê nie, daar sal glad niks wees nie.
En wanneer jy 'n soort groep het, en jy voeg 'n nuwe replika daar by, terwyl dit begin, is alles sleg daarin, dit wil sê dit verhoog sy kas.
Ek het die idee gekry. Die korrekte benadering sou wees om eers 'n klein persentasie navrae op die replika uit te voer, wat die kas sou opwarm. Rofweg gesproke het ons 'n voorwaarde dat ons nie meer as 10 sekondes agter die meester moet bly nie. En hierdie toestand is nie in een golf ingesluit nie, maar glad vir sommige kliënte.
Ja, verhoog gewig.
Dit is 'n goeie idee. Maar eers moet ons hierdie afsluiting implementeer. Eers moet ons afskakel, en dan sal ons dink oor hoe om aan te skakel. Dit is 'n wonderlike kenmerk om glad te aktiveer.
Nginx het hierdie opsie slowly start in 'n groepie vir die bediener. En hy verhoog die las geleidelik.
Ja, goeie idee, ons sal dit probeer wanneer ons daarby uitkom.
Bron: will.com