In zijn rapport zal Andrey Borodin je vertellen hoe ze rekening hebben gehouden met de ervaring met het schalen van PgBouncer bij het ontwerpen van de verbindingspooler , toen ze het in productie brachten. Daarnaast zullen we bespreken welke functies van de puller we graag in nieuwe versies zouden willen zien: het is voor ons belangrijk om niet alleen aan onze behoeften te voldoen, maar ook om de gebruikersgemeenschap te ontwikkelen .
Video:
Dag Allemaal! Mijn naam is Andrew.
Bij Yandex ontwikkel ik open source databases. En vandaag hebben we een onderwerp over verbindingen met poolers.
Als je weet hoe je Connection Pooler in het Russisch moet aanroepen, vertel het me dan. Ik wil heel graag een goede technische term vinden die in de technische literatuur zou moeten worden vastgelegd.
Het onderwerp is behoorlijk ingewikkeld, omdat in veel databases de verbindingspooler is ingebouwd en je er niet eens vanaf hoeft te weten. Natuurlijk zijn er overal wel wat instellingen, maar in Postgres werkt dat niet zo. En parallel (op HighLoad++ 2019) is er een rapport van Nikolai Samokhvalov over het instellen van queries in Postgres. En zoals ik het begrijp, kwamen hier mensen die hun vragen al perfect hadden geconfigureerd, en dit zijn mensen die te maken krijgen met zeldzamere systeemproblemen die verband houden met het netwerk- en bronnengebruik. En op sommige plaatsen kan het behoorlijk lastig zijn, in de zin dat de problemen niet voor de hand liggend zijn.
Yandex heeft Postgres. Veel Yandex-services zijn beschikbaar in Yandex.Cloud. En we hebben verschillende petabytes aan gegevens die in Postgres minstens een miljoen verzoeken per seconde genereren.
En we bieden een redelijk standaard cluster voor alle services - dit is het belangrijkste primaire knooppunt van het knooppunt, de gebruikelijke twee replica's (synchroon en asynchroon), back-up, schaalvergroting van leesverzoeken op de replica.
Elk clusterknooppunt is Postgres, waarop naast Postgres en monitoringsystemen ook een connectiepooler is geïnstalleerd. Connection pooler wordt gebruikt voor hekwerken en voor het hoofddoel ervan.
Wat is het hoofddoel van Connection Pooler?
Postgres hanteert een procesmodel bij het werken met een database. Dit betekent dat één verbinding één proces is, één Postgres-backend. En in deze backend zijn er veel verschillende caches, die behoorlijk duur zijn om verschillend te maken voor verschillende verbindingen.
Bovendien heeft Postgres-code een array met de naam procArray. Het bevat basisgegevens over netwerkverbindingen. En bijna alle procArray-verwerkingsalgoritmen hebben een lineaire complexiteit; ze lopen over de hele reeks netwerkverbindingen. Het is een vrij snelle cyclus, maar met meer inkomende netwerkverbindingen worden de dingen iets duurder. En als het iets duurder wordt, kun je voor veel netwerkverbindingen een hele hoge prijs betalen.
Er zijn 3 mogelijke benaderingen:
- Aan de applicatiekant.
- Aan de databasekant.
- En daartussen, dat wil zeggen, allerlei combinaties.
Helaas is de inbouwpooler momenteel in ontwikkeling. Onze vrienden bij PostgreSQL Professional doen dit vooral. Wanneer het zal verschijnen, is moeilijk te voorspellen. En feitelijk hebben we twee oplossingen waaruit de architect kan kiezen. Dit zijn de pool aan de applicatiezijde en de proxypool.
Zwembad aan de toepassingszijde is de gemakkelijkste manier. En bijna alle clientstuurprogramma's bieden u een manier: miljoenen van uw verbindingen in code presenteren als enkele tientallen verbindingen met de database.
Het probleem dat zich voordoet is dat je op een gegeven moment de backend wilt schalen en deze op veel virtuele machines wilt implementeren.
Dan realiseer je je dat je nog meerdere beschikbaarheidszones hebt, meerdere datacenters. En de aanpak van pooling aan de klantzijde leidt tot grote aantallen. Grote zijn ongeveer 10 aansluitingen. Dit is de rand die normaal kan werken.
Als we het hebben over proxy-poolers, dan zijn er twee poolers die veel dingen kunnen doen. Het zijn niet alleen poolers. Het zijn poolers + meer coole functionaliteit. Dit и .
Maar helaas heeft niet iedereen deze extra functionaliteit nodig. En het leidt ertoe dat poolers alleen sessiepooling ondersteunen, dat wil zeggen één inkomende client en één uitgaande client naar de database.
Dit is niet erg geschikt voor onze doeleinden, dus gebruiken we PgBouncer, dat transactiepooling implementeert, dat wil zeggen dat serververbindingen alleen voor de duur van de transactie worden gekoppeld aan clientverbindingen.
En in onze werklast is dit waar. Maar er zijn een paar problemen.
De problemen beginnen wanneer u een sessie wilt diagnosticeren, omdat al uw inkomende verbindingen lokaal zijn. Iedereen kwam met een loopback en op de een of andere manier wordt het moeilijk om de sessie te traceren.
Natuurlijk kunt u application_name_add_host gebruiken. Dit is een manier aan de Bouncer-kant om een IP-adres toe te voegen aan applicatienaam. Maar applicatie_naam wordt ingesteld door een extra verbinding.
In deze grafiek zijn de gele lijn echte verzoeken en de blauwe lijn de verzoeken die de database binnenkomen. En dit verschil is precies de installatie van applicatie_naam, die alleen nodig is voor tracering, maar helemaal niet gratis is.
Bovendien kunt u in Bouncer niet één pool beperken, d.w.z. het aantal databaseverbindingen per specifieke gebruiker, per specifieke database.
Waar leidt dit toe? Je hebt een geladen service geschreven in C++ en ergens in de buurt een kleine service op een knooppunt die niets vreselijks doet met de database, maar de driver ervan wordt gek. Het opent 20 verbindingen en al het andere zal wachten. Zelfs uw code is normaal.
We hebben natuurlijk een kleine patch voor Bouncer geschreven die deze instelling heeft toegevoegd, d.w.z. het beperken van klanten tot de pool.
Het zou mogelijk zijn om dit aan de Postgres-kant te doen, d.w.z. de rollen in de database te beperken op basis van het aantal verbindingen.
Maar dan verlies je het vermogen om te begrijpen waarom je geen verbindingen met de server hebt. PgBouncer geeft geen verbindingsfout, het retourneert altijd dezelfde informatie. En je begrijpt het niet: misschien is je wachtwoord veranderd, misschien is de database gewoon verloren gegaan, misschien is er iets mis. Maar er is geen diagnose. Als een sessie niet tot stand kan worden gebracht, weet u niet waarom deze niet tot stand kan worden gebracht.
Op een gegeven moment kijk je naar de applicatiegrafieken en zie je dat de applicatie niet werkt.
Kijk naar de bovenkant en zie dat Bouncer single-threaded is. Dit is een keerpunt in het leven van de dienst. U realiseert zich dat u zich aan het voorbereiden was om de database over anderhalf jaar te schalen, en dat u de pooler moet schalen.
We zijn tot de conclusie gekomen dat we meer PgBouncers nodig hebben.
Bouncer is een beetje gepatcht.
En ze zorgden ervoor dat verschillende Bouncers konden worden gegenereerd door de TCP-poort te hergebruiken. En het besturingssysteem draagt binnenkomende TCP-verbindingen automatisch over met behulp van round-robin.
Dit is transparant voor klanten, wat betekent dat het lijkt alsof u één Bouncer heeft, maar dat er sprake is van fragmentatie van inactieve verbindingen tussen actieve Bouncers.
En op een gegeven moment merk je misschien dat deze 3 Bouncers elk hun kern voor 100% opvreten. Je hebt nogal wat Bouncers nodig. Waarom?
Omdat je TLS hebt. Je hebt een gecodeerde verbinding. En als je Postgres vergelijkt met en zonder TLS, zul je merken dat het aantal tot stand gebrachte verbindingen met bijna twee ordes van grootte daalt als encryptie ingeschakeld is, omdat de TLS-handshake CPU-bronnen verbruikt.
En bovenaan zie je een flink aantal cryptografische functies die worden uitgevoerd als er een golf van inkomende verbindingen is. Omdat onze primaire kan schakelen tussen beschikbaarheidszones, is een golf van inkomende verbindingen een vrij typische situatie. Dat wil zeggen dat om de een of andere reden de oude primaire versie niet beschikbaar was, de volledige lading werd naar een ander datacenter gestuurd. Ze komen allemaal tegelijkertijd hallo zeggen tegen TLS.
En een groot aantal TLS-handshakes zegt misschien niet langer gedag tegen Bouncer, maar knijpt in zijn keel. Door de time-out kan de golf van inkomende verbindingen ongedempt worden. Als je opnieuw naar de basis probeert te gaan zonder exponentiële terugtrekking, zullen ze niet steeds opnieuw in een samenhangende golf komen.
Hier is een voorbeeld van 16 PgBouncers die 16 cores op 100% laden.
We kwamen bij de cascade PgBouncer. Dit is de beste configuratie die kan worden bereikt op onze lading met Bouncer. Onze externe Bouncers worden gebruikt voor TCP-handshake, en interne Bouncers worden gebruikt voor echte pooling, om externe verbindingen niet te veel te fragmenteren.
In deze configuratie is een soepele herstart mogelijk. Je kunt al deze 18 Bouncers één voor één opnieuw opstarten. Maar het onderhouden van een dergelijke configuratie is behoorlijk moeilijk. Sysadmins, DevOps en mensen die feitelijk verantwoordelijk zijn voor deze server zullen niet erg blij zijn met deze regeling.
Het lijkt erop dat al onze verbeteringen kunnen worden gepromoot naar open source, maar Bouncer wordt niet erg goed ondersteund. De mogelijkheid om meerdere PgBouncers op één poort te draaien is bijvoorbeeld een maand geleden vastgelegd. Er was een aantal jaren geleden een pull-request voor deze functie.
Of nog een voorbeeld. In Postgres kunt u een lopend verzoek annuleren door het geheim naar een andere verbinding te sturen zonder onnodige authenticatie. Maar sommige clients sturen eenvoudigweg een TCP-reset, dat wil zeggen dat ze de netwerkverbinding verbreken. Wat gaat Bouncer doen? Hij zal niets doen. Het zal het verzoek blijven uitvoeren. Als u een groot aantal verbindingen heeft ontvangen die een database hebben aangemaakt met kleine verzoeken, dan is het eenvoudigweg verbreken van de verbinding met Bouncer niet voldoende; u moet ook de verzoeken voltooien die in de database worden uitgevoerd.
Dit is gepatcht en dit probleem is nog niet opgenomen in de upstream van Bouncer.
En zo kwamen we tot de conclusie dat we een eigen connectiepooler nodig hebben, die ontwikkeld en gepatcht gaat worden, waarin problemen snel verholpen kunnen worden en die uiteraard multi-threaded moet zijn.
We hebben multithreading als hoofdtaak ingesteld. We moeten de golf aan binnenkomende TLS-verbindingen goed kunnen verwerken.
Om dit te doen, moesten we een aparte bibliotheek ontwikkelen, Machinarium genaamd, die is ontworpen om de machinestatussen van een netwerkverbinding als sequentiële code te beschrijven. Als je naar de libpq-broncode kijkt, zie je een aantal behoorlijk complexe oproepen die je een resultaat kunnen opleveren en zeggen: 'Bel me later. Op dit moment heb ik voorlopig IO, maar als de IO wegvalt, zal ik de processor belasten.' En dit is een schema op meerdere niveaus. Netwerkcommunicatie wordt meestal beschreven door een toestandsmachine. Veel regels zoals "Als ik eerder een pakketheader van grootte N heb ontvangen, wacht ik nu op N bytes", "Als ik een SYNC-pakket heb verzonden, wacht ik nu op een pakket met resultaatmetagegevens." Het resultaat is een nogal moeilijke, contra-intuïtieve code, alsof het doolhof is omgezet in lijnscan. We hebben ervoor gezorgd dat de programmeur, in plaats van een toestandsmachine, het hoofdpad van de interactie beschrijft in de vorm van gewone imperatieve code. Het is alleen zo dat je in deze imperatieve code plaatsen moet invoegen waar de uitvoeringsreeks moet worden onderbroken door te wachten op gegevens van het netwerk, waarbij de uitvoeringscontext wordt doorgegeven aan een andere coroutine (groene draad). Deze aanpak is vergelijkbaar met het feit dat we het meest verwachte pad in het doolhof op een rij opschrijven en er vervolgens vertakkingen aan toevoegen.
Als resultaat hebben we één thread die TCP accepteert en round-robin geeft de TPC-verbinding door aan veel werknemers.
In dit geval draait elke clientverbinding altijd op één processor. En hierdoor kunt u het cachevriendelijk maken.
En daarnaast hebben we de verzameling van kleine pakketten in één groot pakket enigszins verbeterd om de TCP-stack van het systeem te ontlasten.
Daarnaast hebben we de transactionele pooling verbeterd in die zin dat Odyssey, indien geconfigureerd, CANCEL en ROLLBACK kan verzenden in het geval van een netwerkverbindingsfout, d.w.z. als niemand op een verzoek wacht, zal Odyssey de database vertellen om niet te proberen het verzoek vervullen dat kostbare hulpbronnen kan verspillen.
En waar mogelijk houden we verbindingen met dezelfde klant. Dit voorkomt dat u application_name_add_host opnieuw moet installeren. Als dit mogelijk is, hoeven we de parameters die nodig zijn voor de diagnose niet extra te resetten.
Wij werken in het belang van Yandex.Cloud. En als u beheerde PostgreSQL gebruikt en een verbindingspooler hebt geïnstalleerd, kunt u logische replicatie naar buiten toe creëren, d.w.z. laat ons, als u dat wilt, logische replicatie gebruiken. Bouncer zal de logische replicatiestroom niet naar buiten vrijgeven.
Dit is een voorbeeld van het instellen van logische replicatie.
Daarnaast hebben we ondersteuning voor fysieke replicatie naar buiten toe. In de Cloud is dit uiteraard onmogelijk, omdat het cluster je dan te veel informatie over zichzelf geeft. Maar als u in uw installaties fysieke replicatie nodig heeft via de verbindingspooler in Odyssey, is dit mogelijk.
Odyssey heeft volledig compatibele monitoring met PgBouncer. We hebben dezelfde console die bijna allemaal dezelfde opdrachten uitvoert. Als er iets ontbreekt, stuur dan een pull-request, of op zijn minst een issue op GitHub, en we zullen de nodige commando's voltooien. Maar we hebben al de hoofdfunctionaliteit van de PgBouncer-console.
En natuurlijk hebben we het doorsturen van fouten. We zullen de door de database gerapporteerde fout retourneren. U krijgt informatie over waarom u niet in de database staat, en niet alleen dat u er niet in staat.
Deze functie is uitgeschakeld als u 100% compatibiliteit met PgBouncer nodig heeft. Voor de zekerheid kunnen we ons op dezelfde manier gedragen als Bouncer.
ontwerp
Een paar woorden over de Odyssey-broncode.
Er zijn bijvoorbeeld “Pauzeer / Hervat”-opdrachten. Ze worden meestal gebruikt om de database bij te werken. Als u Postgres moet bijwerken, kunt u dit onderbreken in de verbindingspooler, pg_upgrade uitvoeren en vervolgens hervatten. En vanaf de kant van de klant zal het lijken alsof de database simpelweg langzamer gaat werken. Deze functionaliteit is ons aangeboden door mensen uit de gemeenschap. Ze is nog niet bevroren, maar binnenkort zal alles dat zijn. (Reeds bevroren)
- al bevroren
Bovendien is een van de nieuwe functies in PgBouncer ondersteuning voor SCRAM Authentication, die ons ook werd aangeboden door iemand die niet in Yandex.Cloud werkt. Beide zijn complexe functionaliteit en belangrijk.
Daarom wil ik je graag vertellen waar Odyssey van gemaakt is, voor het geval je nu ook een beetje code wilt schrijven.
Je hebt de Odyssey-bronbasis, die afhankelijk is van twee hoofdbibliotheken. De Kiwi-bibliotheek is een implementatie van het Postgres-berichtenprotocol. Dat wil zeggen, native proto 3 van Postgres zijn standaardberichten die front-ends en back-ends kunnen uitwisselen. Ze zijn geïmplementeerd in de Kiwi-bibliotheek.
De Machinarium-bibliotheek is een threadimplementatiebibliotheek. Een klein fragment van dit Machinarium is geschreven in assembleertaal. Maar wees niet ongerust, er zijn slechts 15 regels.
Odyssee-architectuur. Er is een hoofdmachine waarop coroutines draaien. Deze machine implementeert het accepteren van inkomende TCP-verbindingen en distribueert deze onder werknemers.
Binnen één medewerker kan een behandelaar voor meerdere opdrachtgevers werken. De hoofdthread voert ook de console en de verwerking van crone-taken uit om verbindingen te verwijderen die niet langer nodig zijn in de pool.
Odyssey wordt getest met behulp van de standaard Postgres-testsuite. We voeren gewoon de installatiecontrole uit via Bouncer en via Odyssey krijgen we een nuldiv. Er zijn verschillende tests met betrekking tot datumnotatie die niet precies hetzelfde doorstaan in Bouncer en in Odyssey.
Daarnaast zijn er veel chauffeurs die hun eigen keuringen hebben. En we gebruiken hun tests om de Odyssey te testen.
Daarnaast moeten we vanwege onze cascadeconfiguratie verschillende bundels testen: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey om er zeker van te zijn dat als Odyssey in een van de onderdelen in de cascade terechtkomt, deze ook nog werkt zoals we verwachten.
hark
We gebruiken Odyssey in de productie. En het zou niet eerlijk zijn als ik zou zeggen dat alles gewoon werkt. Nee, dat wil zeggen, ja, maar niet altijd. In de productie werkte alles bijvoorbeeld gewoon, toen kwamen onze vrienden van PostgreSQL Professional en zeiden dat we een geheugenlek hadden. Dat waren ze echt, we hebben ze gecorrigeerd. Maar het was eenvoudig.
Toen ontdekten we dat de verbindingspooler inkomende TLS-verbindingen en uitgaande TLS-verbindingen heeft. En voor verbindingen zijn clientcertificaten en servercertificaten vereist.
Bouncer- en Odyssey-servercertificaten worden opnieuw gelezen door hun pcache, maar clientcertificaten hoeven niet opnieuw te worden gelezen vanuit pcache, omdat onze schaalbare Odyssey uiteindelijk de systeemprestaties van het lezen van dit certificaat tegenkomt. Dit kwam voor ons als een verrassing, omdat het niet lang duurde voordat hij zich verzette. In eerste instantie schaalde het lineair op, maar na 20 inkomende gelijktijdige verbindingen deed dit probleem zich voor.
Pluggable Authenticatiemethode is de mogelijkheid om te authenticeren met behulp van ingebouwde Lunux-tools. In PgBouncer is het zo geïmplementeerd dat er een aparte thread is om te wachten op een reactie van PAM en er is een hoofdthread van PgBouncer die de huidige verbinding bedient en hen kan vragen om in de PAM-thread te leven.
Om een simpele reden hebben we dit niet geïmplementeerd. We hebben veel draadjes. Waarom hebben we dit nodig?
Dit kan uiteindelijk tot problemen leiden omdat als je PAM-authenticatie en niet-PAM-authenticatie hebt, een grote golf van PAM-authenticatie de niet-PAM-authenticatie aanzienlijk kan vertragen. Dit is een van die dingen die we nog niet hebben opgelost. Maar als je het wilt repareren, kun je dit doen.
Een ander pluspunt was dat we één thread hebben die alle inkomende verbindingen accepteert. En vervolgens worden ze overgebracht naar de werknemerspool, waar de TLS-handshake zal plaatsvinden.
Kortom, als je een samenhangende golf van 20 netwerkverbindingen hebt, worden ze allemaal geaccepteerd. En aan de clientzijde zal libpq beginnen met het rapporteren van time-outs. Standaard lijkt dit 000 seconden te zijn.
Als ze niet allemaal tegelijkertijd de database kunnen betreden, kunnen ze de database niet betreden, omdat dit allemaal kan worden gedekt door niet-exponentiële nieuwe pogingen.
We kwamen tot de conclusie dat we het schema van PgBouncer hier hebben gekopieerd, met het feit dat we het aantal TCP-verbindingen hebben beperkt dat we accepteren.
Als we zien dat we verbindingen accepteren, maar ze uiteindelijk geen tijd hebben om te handshaken, plaatsen we ze in een wachtrij zodat ze geen CPU-bronnen verspillen. Dit leidt ertoe dat niet voor alle binnengekomen verbindingen een gelijktijdige handshake kan worden uitgevoerd. Maar er komt tenminste iemand in de database, ook al is de belasting behoorlijk zwaar.
roadmap
Wat zou jij in de toekomst graag zien in Odyssey? Wat zijn wij bereid om zelf te ontwikkelen en wat verwachten wij van de gemeenschap?
Vanaf augustus 2019.
Zo zag de Odyssey-routekaart er in augustus uit:
- We wilden SCRAM- en PAM-authenticatie.
- We wilden leesverzoeken doorsturen naar stand-by.
- Ik wil graag een online herstart.
- En de mogelijkheid om te pauzeren op de server.
De helft van dit stappenplan is voltooid, en niet door ons. En dit is goed. Laten we dus bespreken wat er overblijft en er meer aan toevoegen.
? We hebben replica's die eenvoudigweg de lucht verwarmen zonder verzoeken uit te voeren. We hebben ze nodig voor failover en omschakeling. Als er problemen zijn in een van de datacenters, wil ik ze graag met nuttig werk bezighouden. Omdat we niet dezelfde centrale processors, hetzelfde geheugen anders kunnen configureren, omdat replicatie anders niet werkt.
In principe is het in Postgres vanaf 10 mogelijk om session_attrs op te geven bij het verbinden. U kunt alle databasehosts in de verbinding vermelden en aangeven waarom u naar de database gaat: alleen schrijven of alleen lezen. En de bestuurder selecteert zelf de eerste host in de lijst die hij het leukst vindt, die voldoet aan de vereisten van session_attrs.
Maar het probleem met deze aanpak is dat deze de replicatievertraging niet onder controle houdt. Het kan zijn dat u een replica heeft die onaanvaardbaar lang achterloopt op uw service. Om volledige uitvoering van leesquery's op een replica mogelijk te maken, moeten we in wezen de mogelijkheid van Odyssey ondersteunen om niet te worden uitgevoerd als deze niet kan worden gelezen.
Odyssey moet van tijd tot tijd naar de database gaan en de replicatieafstand van de primaire database opvragen. En als de limietwaarde is bereikt, sta dan geen nieuwe verzoeken toe in de database, vertel de klant dat hij de verbindingen opnieuw moet initiëren en selecteer mogelijk een andere host om verzoeken uit te voeren. Hierdoor kan de database de replicatievertraging snel herstellen en weer terugkeren om te reageren met een verzoek.
Het is moeilijk om een tijdsbestek voor de implementatie te geven, omdat het open source is. Maar ik hoop niet 2,5 jaar zoals mijn collega's van PgBouncer. Dit is het kenmerk dat ik graag in de Odyssee zou willen zien.
. Nu kunt u op twee manieren een voorbereide verklaring maken. Ten eerste kunt u het SQL-commando uitvoeren, namelijk "prepared". Om dit SQL-commando te begrijpen, moeten we de SQL aan de Bouncer-kant leren begrijpen. Dit zou overdreven zijn, omdat het overdreven is, omdat we de hele parser nodig hebben. We kunnen niet elke SQL-opdracht parseren.
Maar er is een voorbereide verklaring op berichtprotocolniveau op proto3. En dit is de plaats waar de informatie dat een voorbereide verklaring wordt opgesteld, in een gestructureerde vorm komt. En we zouden het inzicht kunnen ondersteunen dat de klant bij een bepaalde serververbinding vroeg om voorbereide verklaringen te maken. En zelfs als de transactie is afgerond, moeten we nog steeds de connectiviteit tussen de server en de client in stand houden.
Maar hier ontstaat er een discrepantie in de dialoog, omdat iemand zegt dat je moet begrijpen wat voor soort voorbereide verklaringen de client heeft gemaakt en de serververbinding moet delen tussen alle clients die deze serververbinding hebben gemaakt, dat wil zeggen, die zo'n voorbereide verklaring hebben gemaakt.
Andres Freund zei dat als een klant naar je toe komt die al zo'n voorbereide verklaring in een andere serververbinding heeft gemaakt, deze dan voor hem moet maken. Maar het lijkt een beetje verkeerd om queries in de database uit te voeren in plaats van in de client, maar vanuit het perspectief van de ontwikkelaar die het protocol schrijft voor interactie met de database zou het handig zijn als hij simpelweg een netwerkverbinding zou krijgen waarin er is zo'n voorbereide vraag.
En nog een functie die we moeten implementeren. We hebben nu monitoring compatibel met PgBouncer. We kunnen de gemiddelde uitvoeringstijd van de query retourneren. Maar de gemiddelde tijd is de gemiddelde temperatuur in het ziekenhuis: sommige zijn koud, andere zijn warm - gemiddeld is iedereen gezond. Het is niet waar.
We moeten ondersteuning implementeren voor percentielen die erop wijzen dat er langzame query's zijn die middelen verspillen en monitoring acceptabeler maken.
Het belangrijkste is dat ik versie 1.0 wil (versie 1.1 is al uitgebracht). Feit is dat Odyssey nu in versie 1.0rc zit, oftewel release candidate. En alle problemen die ik opsomde, werden opgelost met exact dezelfde versie, behalve het geheugenlek.
Wat gaat versie 1.0 voor ons betekenen? We rollen Odyssey uit naar onze bases. Het draait al in onze databases, maar wanneer het het punt van 1 verzoeken per seconde bereikt, kunnen we zeggen dat dit de releaseversie is en dat dit een versie is die 000 kan worden genoemd.
Verschillende mensen in de gemeenschap hebben gevraagd dat versie 1.0 pauze en SCRAM bevat. Maar dit betekent dat we de volgende versie naar productie moeten brengen, omdat noch SCRAM noch Pause nog zijn gedood. Maar hoogstwaarschijnlijk zal dit probleem vrij snel worden opgelost.
Ik wacht op je pull-verzoek. Ik zou ook graag willen horen welke problemen u heeft met Bouncer. Laten we ze bespreken. Misschien kunnen we enkele functies implementeren die u nodig heeft.
Dit is het einde van mijn deel, ik zou graag naar je willen luisteren. Bedankt!
vragen
Als ik mijn eigen applicatienaam instel, wordt deze dan correct doorgestuurd, ook bij transactiepooling in Odyssey?
Odyssee of uitsmijter?
In Odyssee. In Bouncer wordt er gegooid.
We doen een setje.
En als mijn echte verbinding op andere verbindingen springt, wordt deze dan verzonden?
We zullen een set maken van alle parameters die in de lijst staan. Ik weet niet of applicatie_naam in deze lijst staat. Ik denk dat ik hem daar heb gezien. We zullen allemaal dezelfde parameters instellen. Met één verzoek doet de set alles wat tijdens het opstarten door de klant is geïnstalleerd.
Bedankt, Andrey, voor het rapport! Goed rapport! Ik ben blij dat Odyssey zich elke minuut sneller en sneller ontwikkelt. Ik wil zo doorgaan. We hebben u al gevraagd om een verbinding met meerdere gegevensbronnen te hebben, zodat Odyssey tegelijkertijd verbinding kan maken met verschillende databases, d.w.z. een master-slave, en vervolgens na een failover automatisch verbinding kan maken met een nieuwe master.
Ja, ik meen mij deze discussie te herinneren. Nu zijn er verschillende opslagruimtes. Maar er wordt niet tussen hen gewisseld. Aan onze kant moeten we de server ondervragen of deze nog leeft en begrijpen dat er een failover heeft plaatsgevonden, die pg_recovery zal aanroepen. Ik heb een standaardmanier om te begrijpen dat we niet bij de meester zijn gekomen. En moeten we op de een of andere manier iets begrijpen van de fouten of zo? Dat wil zeggen, het idee is interessant, het wordt besproken. Schrijf meer opmerkingen. Als je werknemers hebt die C kennen, dan is dat geweldig.
De kwestie van het schalen tussen replica's is ook van belang voor ons, omdat we de adoptie van gerepliceerde clusters zo eenvoudig mogelijk willen maken voor applicatieontwikkelaars. Maar hier zou ik graag meer commentaar willen, d.w.z. hoe je het precies moet doen, hoe je het goed moet doen.
De vraag gaat ook over replica's. Het blijkt dat je een meester en verschillende replica's hebt. En het is duidelijk dat ze voor verbindingen minder vaak naar de replica gaan dan naar de master, omdat ze mogelijk verschillen hebben. U zei dat het verschil in de gegevens zo groot kan zijn dat het uw bedrijf niet tevreden zal stellen en dat u daar niet heen zult gaan totdat het is gerepliceerd. Tegelijkertijd, als u daar lange tijd niet bent geweest en vervolgens bent begonnen, zullen de benodigde gegevens niet onmiddellijk beschikbaar zijn. Dat wil zeggen, als we constant naar de master gaan, wordt de cache daar opgewarmd, maar in de replica blijft de cache een beetje achter.
Ja het is waar. De pcache zal niet de gewenste datablokken bevatten, de echte cache zal geen informatie bevatten over de gewenste tabellen, de plannen zullen geen geparseerde queries bevatten, er zal helemaal niets zijn.
En als je een soort cluster hebt, en je voegt daar een nieuwe replica aan toe, dan is tijdens het starten alles slecht daarin, dat wil zeggen dat het de cache vergroot.
Ik heb het idee. De juiste aanpak zou zijn om eerst een klein percentage van de query's op de replica uit te voeren, waardoor de cache zou worden opgewarmd. Grofweg stellen we als voorwaarde dat we maximaal 10 seconden achterlopen op de meester. En deze voorwaarde is niet in één golf opgenomen, maar voor sommige klanten soepel.
Ja, gewicht verhogen.
Dit is een goed idee. Maar eerst moeten we deze afsluiting implementeren. Eerst moeten we uitschakelen, en dan zullen we nadenken over hoe we het kunnen inschakelen. Dit is een geweldige functie om soepel in te schakelen.
Nginx heeft deze optie slowly start in een cluster voor de server. En hij verhoogt geleidelijk de belasting.
Ja, geweldig idee, we zullen het proberen als we er aan toe zijn.
Bron: www.habr.com