In het verslag zal Andrej Borodin uitleggen hoe ze de ervaring van het schalen van PgBouncer hebben toegepast bij het ontwerpen van de connection pooler. , hoe ze het in productie hebben uitgerold. Daarnaast bespreken we welke functies we in nieuwe versies van de pooler zouden willen zien: het is voor ons belangrijk om niet alleen onze behoeften te vervullen, maar ook de gemeenschap van gebruikers te ontwikkelen. .
Video:
Hallo iedereen! Mijn naam is Andrej.
Bij Yandex ben ik betrokken bij de ontwikkeling van open source databases. Vandaag hebben we het onderwerp connection pooler.
Als je weet hoe je connection pooler in het Nederlands noemt, laat het me weten. Ik wil graag een goede technische term vinden die in de technische literatuur moet vestigen.
Het onderwerp is behoorlijk complex omdat veel databases een ingebouwde connection pooler hebben en je er zelfs niet over na hoeft te denken. Er zijn natuurlijk wel wat instellingen, maar het werkt niet zo in Postgres. Parallel aan deze sessie (op HighLoad++ 2019) geeft Nikolai Samokhvalov een presentatie over het afstemmen van queries in Postgres. En ik begrijp dat hier mensen zijn gekomen die hun queries al perfect hebben afgestemd, en dat zijn de mensen die te maken hebben met zeldzamere systeemproblemen, gerelateerd aan netwerken en resource-utilisatie. Sommige aspecten kunnen behoorlijk ingewikkeld zijn omdat de problemen niet altijd voor de hand liggen.
In Yandex is er Postgres. In Yandex Cloud wonen veel van Yandex's diensten. En we hebben enkele petabytes aan gegevens die niet minder dan een miljoen verzoeken per seconde in Postgres genereren.
En we bieden een vrij standaard cluster voor alle diensten aan – dit is de primaire node van het cluster, samen met twee reguliere replica's (één synchronisch en één asynchronisch), back-ups, en het schalen van leesverzoeken op de replica.
Elke node in het cluster is Postgres, waarop naast Postgres en systeemonitoring ook een connection pooler is geïnstalleerd. De connection pooler wordt gebruikt voor fencing en zijn primaire functie.
Wat is de primaire functie van een connection pooler?
In Postgres wordt een procesmodel gevolgd bij het werken met de database. Dit betekent dat één verbinding één proces is, één backend van Postgres. En in deze backend zijn er veel verschillende caches, die vrij kostbaar zijn om verschillend te maken voor verschillende verbindingen.
Daarnaast bevat de Postgres-code een array die procArray wordt genoemd. Dit bevat de belangrijkste gegevens over netverbindingen. En bijna alle algoritmes voor het verwerken van procArray hebben een lineaire complexiteit, omdat ze door de hele array van netverbindingen gaan. Dit is een vrij snelle cyclus, maar met een groot aantal inkomende netverbindingen wordt het allemaal iets duurder. En wanneer alles iets duurder wordt, kan het uiteindelijk heel veel kosten voor een groot aantal netverbindingen.
Er zijn 3 mogelijke benaderingen:
- Aan de applicatiekant.
- Aan de databasekant.
- En er tussenin, dat wil zeggen, allerlei combinaties.
Helaas is de ingebouwde pooler momenteel in ontwikkeling. Vrienden bij PostgreSQL Professional werken hier voornamelijk aan. Wanneer deze beschikbaar komt, is moeilijk te voorspellen. En feitelijk heeft de architect de keuze uit twee oplossingen. Dit is application-side pool en proxy pool.
Application-side pool is de eenvoudigste manier. En bijna alle client-drivers bieden je de mogelijkheid: miljoenen van je verbindingen in de code voorstellen als enkele tientallen verbindingen naar de database.
Er ontstaat een probleem wanneer je op een bepaald moment de backend wilt schalen en deze op verschillende virtuele machines wilt uitrollen.
Vervolgens realiseer je je ook dat je meerdere beschikbaarheidszones en verschillende datacenters hebt. En de aanpak met client-side pooling leidt tot grote aantallen. Groot betekent ongeveer 10.000 verbindingen. Dat is de grens waarop het redelijk kan functioneren.
Als we het hebben over proxy poolers, zijn er twee poolers die veel kunnen. Het zijn niet alleen poolers. Ze zijn poolers + met een geweldige functionaliteit. Dit is en .
Maar helaas is die extra functionaliteit niet voor iedereen nodig. En het leidt ertoe dat poolers alleen sessie-pooling ondersteunen, dat wil zeggen, één inkomende client, één uitgaande client naar de database.
Voor onze behoeften past dit niet goed, daarom gebruiken we PgBouncer, dat transaction pooling implementeert, dat wil zeggen, serververbindingen worden alleen voor de duur van de transactie toegewezen aan clientverbindingen.
En onder onze belasting is dat waar. Maar er zijn een paar problemen..
Problemen beginnen wanneer je een sessie wilt diagnosticeren, omdat al je inkomende verbindingen lokaal zijn. Ze komen allemaal van loopback en het wordt moeilijk om een sessie te traceren.
Natuurlijk kunt u application_name_add_host gebruiken. Dit is een manier aan de Bouncer-kant om een IP-adres aan application_name toe te voegen. Maar application_name wordt ingesteld via een extra verbinding.
In deze grafiek, waar de gele lijn de werkelijke verzoeken weergeeft en de blauwe lijn de verzoeken die de database bereiken. En dit verschil is precies de instelling van application_name, wat alleen nodig is voor tracering, maar helemaal niet gratis is.
Bovendien kunt u in Bouncer niet één pool beperken, dat wil zeggen het aantal verbindingen met de database voor een bepaalde gebruiker, voor een bepaalde database.
Waar leidt dit toe? U hebt een zwaar belaste service, geschreven in C++, en ergens dichtbij een kleine service op Node, die vrij onschuldig met de database omgaat, maar zijn driver gaat totaal door het lint. Het opent 20.000 verbindingen, en de rest kan wachten. Uw code is zelfs normaal.
We hebben natuurlijk een kleine patch voor Bouncer geschreven, die deze instelling toevoegt, dat wil zeggen, het beperken van klanten tot een pool.
Dit zou mogelijk zijn aan de Postgres-kant, dat wil zeggen, rollen in de database beperken tot een bepaald aantal verbindingen.
Maar dan verliest u de mogelijkheid om te begrijpen waarom er geen verbindingen met de server zijn. PgBouncer geeft geen verbindingsfout door, hij retourneert altijd dezelfde informatie. En u kunt niet begrijpen: misschien is uw wachtwoord veranderd, misschien is de database gewoon gecrasht, misschien is er iets mis. Maar er is geen diagnose. Als de sessie niet kan worden ingesteld, komt u er niet achter waarom dit niet kan worden gedaan.
Op een bepaald moment kijkt u naar de grafieken van de applicatie en ziet u dat de applicatie niet werkt.
U kijkt naar de top en ziet dat Bouncer single-threaded is. Dit is een keerpunt in het leven van de service. U realiseert zich dat u zich had voorbereid op de schaling van de database over anderhalf jaar, maar dat u de pooler moet schalen.
We zijn tot de conclusie gekomen dat we meer PgBouncer's nodig hebben.
We hebben Bouncer een beetje gepatcht.
En we hebben het zo gemaakt dat meerdere Bouncers kunnen worden opgestart met hergebruik van de TCP-poort. En de besturingssystemen herverdelen automatisch de binnenkomende TCP-verbindingen tussen hen in round-robin.
Dit is transparant voor klanten, dat wil zeggen, alles ziet eruit alsof u één Bouncer hebt, maar er is fragmentatie van idle-verbindingen tussen de actieve Bouncer's.
En op een gegeven moment merkt u misschien dat deze 3 Bouncers elk 100% van hun kern gebruiken. U heeft behoorlijk wat Bouncers nodig. Waarom?
Omdat u TLS heeft. U heeft een versleutelde verbinding. En als u Postgres benchmarkt met en zonder TLS, zult u merken dat het aantal gevestigde verbindingen met bijna twee orden afneemt bij inschakeling van versleuteling, omdat de TLS handshake CPU-bronnen verbruikt.
En aan de top kunt u een behoorlijk aantal cryptografische functies zien die worden uitgevoerd tijdens de golf van binnenkomende verbindingen. Aangezien onze primaire database kan schakelen tussen beschikbaarheidszones, is een golf van binnenkomende verbindingen een vrij typische situatie. Dat wil zeggen, om de een of andere reden was de oude primaire database niet beschikbaar, en de hele belasting werd naar een ander datacenter gestuurd. Ze zullen allemaal tegelijk komen om zich met TLS voor te stellen.
En een groot aantal TLS handshakes kan niet meer met Bouncer begroeten, maar het kan hem verstikken. Vanwege de time-out kan de golf van binnenkomende verbindingen onophoudelijk worden. Als u opnieuw probeert naar de database zonder exponentiële backoff, zullen ze telkens weer in een coherente golf binnenkomen.
Hier is een voorbeeld van 16 PgBouncers die 16 kernen op 100% belasten.
We zijn gekomen tot cascade PgBouncer. Dit is de beste configuratie die we kunnen bereiken met onze belasting op Bouncer. Externe Bouncers dienen voor de TCP handshake, terwijl interne Bouncers dienen voor de werkelijke pooling, om externe verbindingen niet te veel te fragmenteren.
In deze configuratie is een soepele herstart mogelijk. U kunt al deze 18 Bouncers één voor één herstarten. Maar het onderhouden van zulke configuraties is behoorlijk moeilijk. Systeembeheerders, DevOps en mensen die daadwerkelijk verantwoordelijk zijn voor deze server, zullen niet blij zijn met zo'n schema.
Het lijkt erop dat we al onze aanpassingen in open source kunnen doorvoeren, maar Bouncer wordt niet zo goed ondersteund. Bijvoorbeeld, de mogelijkheid om meerdere PgBouncers op één poort te draaien is een maand geleden gecommit. En de pull request voor deze functie was enkele jaren geleden.
Of een ander voorbeeld. In Postgres kunt u een lopende query annuleren door een geheim naar een andere verbinding te sturen zonder extra authenticatie. Maar sommige clients sturen gewoon een TCP-reset, dat wil zeggen, ze verbreken de netwerkverbinding. Wat doet Bouncer dan? Hij doet niets. Hij blijft de query uitvoeren. Als u een enorme hoeveelheid verbindingen heeft die kleine queries naar de database sturen, is het gewoon niet voldoende om de verbinding met Bouncer te verbreken; u moet ook die queries beëindigen die in de database draaien.
Dit is gepatcht en dit probleem is nog steeds niet opgenomen in de upstream van Bouncer.
En zo kwamen we tot de conclusie dat we onze eigen connection pooler nodig hebben, die zal ontwikkelen, gepatcht kan worden, waarin we snel problemen kunnen oplossen en die natuurlijk multi-threaded moet zijn.
Multi-threading hebben we als een hoofddoel gesteld. We moeten de golf van binnenkomende TLS-verbindingen goed kunnen verwerken.
Hiervoor moesten we een aparte bibliotheek ontwikkelen die Machinarium heet, die bedoeld is om de machine-toestanden van een netwerkverbinding als sequentiële code te beschrijven. Als u naar de broncode van libpq kijkt, ziet u vrij complexe aanroepen die u een resultaat kunnen retourneren en zeggen: 'Bel me later nog eens. Nu heb ik IO, maar wanneer de IO voorbij is, heb ik CPU-belasting'. En dit is een meerlaags schema. Netwerkinteractie wordt gewoonlijk beschreven als een toestandsmachine. Met veel regels zoals 'Als ik eerder een pakketkop met grootte N heb ontvangen, wacht ik nu op N bytes', 'Als ik een SYNC-pakket heb verzonden, wacht ik nu op een pakket met metadata van het resultaat'. Dit resulteert in vrij moeilijke en intuïtief tegenstrijdige code, alsof een doolhof wordt omgevormd in een lineaire ontroling. We hebben het zo gemaakt dat in plaats van een toestandsmachine, de programmeur de hoofdroute van de interactie beschrijft in de vorm van gewone imperatieve code. Gewoon, in deze imperatieve code moeten plekken worden ingevoegd waar de volgorde van uitvoering moet worden onderbroken door te wachten op gegevens van het netwerk, door de uitvoeringscontext aan een andere coroutine (groene thread) door te geven. Deze aanpak is vergelijkbaar met het feit dat we de meest verwachte route in de doolhof meteen opschrijven en er vervolgens vertakkingen aan toevoegen.
Uiteindelijk hebben we één thread die TCP accept doet en via round-robin meerdere workers TPC-verbindingen doorgeeft.
Elk klantverbinding draait altijd op één processor. Dit maakt het cachevriendelijk.
Bovendien hebben we een verbetering aangebracht in het verzamelen van kleine pakketten in één groot pakket om de systeem-TCP-stack te ontlasten.
Daarnaast hebben we de transaction pooling verbeterd, zodat Odyssey bij de juiste instelling CANCEL en ROLLBACK kan verzenden in geval van een netwerkonderbreking, d.w.z. als er niemand op de aanvraag wacht, zal Odyssey tegen de database zeggen dat deze niet hoeft te proberen de aanvraag uit te voeren, die waardevolle middelen kan verbruiken.
Waar mogelijk behouden we verbindingen voor dezelfde klant. Dit voorkomt dat application_name_add_host opnieuw moet worden ingesteld. Indien mogelijk hebben we geen extra herinstelling van parameters die nodig zijn voor diagnostiek.
Wij werken in het belang van Yandex.Cloud. En als je managed PostgreSQL gebruikt en je hebt een connection pooler ingesteld, dan kun je logische replicatie naar buiten creëren, d.w.z. je kunt van ons weggaan als je dat wilt, middels logische replicatie. De Bouncer geeft de stroom van logische replicatie niet naar buiten.
Dit is een voorbeeld van de configuratie van logische replicatie.
Bovendien hebben we ondersteuning voor fysieke replicatie naar buiten. In de cloud is dit natuurlijk niet mogelijk, omdat je cluster dan te veel informatie over zichzelf zou geven. Maar in jouw installaties, als je fysieke replicatie via een connection pooler in Odyssey nodig hebt, is dat mogelijk.
In Odyssey is er volledige compatibele monitoring met PgBouncer. We hebben dezelfde console die bijna dezelfde commando's uitvoert. Als er iets ontbreekt, stuur dan een pull request, of tenminste een issue op GitHub, en we zullen de benodigde commando's afmaken. Maar de belangrijkste functionaliteit van de PgBouncer-console hebben we al.
En natuurlijk hebben we error forwarding. We geven de fout terug die de database heeft gemeld. Je krijgt informatie over waarom je geen toegang hebt tot de database, en niet alleen dat je er niet in komt.
Deze functie kan worden uitgeschakeld als je 100% compatibiliteit met PgBouncer nodig hebt. We kunnen ons gedragen als Bouncer, gewoon voor de zekerheid.
Ontwikkeling
Een paar woorden over de broncode van Odyssey.
Bijvoorbeeld, er zijn de commando's 'Pause / Resume'. Deze worden meestal gebruikt voor het bijwerken van de database. Als je Postgres moet bijwerken, kun je het in de connection pooler op pauze zetten, pgr_upgraden, en daarna weer hervatten. Voor de klant zal het lijken alsof de database gewoon traag was. Deze functionaliteit is ons gebracht door mensen uit de gemeenschap. Het is nog niet samengevoegd, maar het komt snel. (Al samengevoegd)
— al samengevoegd
Bovendien is een van de nieuwe functies in PgBouncer de ondersteuning van SCRAM-authenticatie, die ons ook is gebracht door iemand die niet bij Yandex.Cloud werkt. Beide zijn complexe functionaliteiten en belangrijk.
Daarom willen we vertellen waaruit Odyssey is gemaakt, misschien wil je ook een beetje code schrijven.
Je hebt de basisversie van Odyssey, die afhankelijk is van twee belangrijke bibliotheken. De Kiwi-bibliotheek is een implementatie van het Postgres-berichtprotocol. Dat wil zeggen, de native proto 3 bij Postgres zijn de standaardberichten waarmee front-ends en back-ends kunnen communiceren. Deze zijn geïmplementeerd in de Kiwi-bibliotheek.
De Machinarium-bibliotheek is een bibliotheek voor de implementatie van streams. Een klein fragment van deze Machinarium is geschreven in assembly. Maar maak je geen zorgen, het zijn slechts 15 regels.
De architectuur van Odyssey. Er is een hoofdmachine waarin coroutines draaien. In deze machine worden binnenkomende TCP-verbindingen geaccepteerd en verdeeld over workers.
Binnen één worker kan een handler voor meerdere klanten werken. Daarnaast draaien de console en de verwerking van cron-taken in de hoofdthread voor het verwijderen van verbindingen die niet meer nodig zijn in de pool.
Voor het testen van Odyssey gebruiken we de standaard set tests van Postgres. We draaien gewoon install-check via Bouncer en via Odyssey, en krijgen een nul div. Er zijn verschillende tests die verband houden met datumformattering die absoluut niet hetzelfde passeren in Bouncer en in Odyssey.
Daarnaast zijn er veel drivers die hun eigen testen hebben. En we gebruiken hun tests voor het testen van Odyssey.
Bovendien moeten we vanwege onze cascadeconfiguratie verschillende combinaties testen: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, om er zeker van te zijn dat als Odyssey in een van de delen van de cascade terechtkomt, het nog steeds werkt zoals we verwachten.
Harken
We use Odyssey in production. It would be unfair to say that everything just works. No, it does, but not always. For example, in production, everything worked fine until our friends from PostgreSQL Professional pointed out that we had a memory leak. They were indeed correct, and we fixed it. But that was just the beginning.
Then we discovered that the connection pooler has incoming TLS connections and outgoing TLS connections. And these connections require client certificates and server certificates.
The server certificates for Bouncer and Odyssey read from their pcache, but client certificates do not need to be re-read from pcache because our scalable Odyssey eventually hits the performance limits of reading that certificate. This took us by surprise because it didn't happen immediately. Initially, it scaled linearly, but after 20,000 simultaneous incoming connections, this issue became apparent.
Pluggable Authentication Method is a way to authenticate using built-in Linux tools. In PgBouncer, it is implemented such that there is a separate thread for waiting for a response from PAM and a main PgBouncer thread that handles the current connection and can ask them to reside in the PAM thread.
We didn't implement this for one simple reason. We have many threads. Why do we need this?
Ultimately, this can create problems in cases where you have PAM authentication and non-PAM authentication, as a large wave of PAM authentication can significantly delay non-PAM authentication. This is one of those issues that we haven't fixed. But if you want to address it, you can look into this.
Another issue we encountered was having one thread that accepts all incoming connections and then passes them to the worker pool, where the TLS handshake will occur.
As a result, if you have a coherent wave of 20,000 network connections, they will all be accepted. On the client side, libpq will start the timeout countdown. By default, it seems to set at 3 seconds.
If they all cannot access the database simultaneously, they won't be able to access it because all of this may be covered by non-exponential retry.
We ended up copying the scheme from PgBouncer with throttling the number of TCP connections that we accept.
Als we zien dat we verbindingen accepteren, maar ze uiteindelijk de handshake niet kunnen voltooien, zetten we ze in de wachtrij zodat ze geen centrales processorresources verbruiken. Dit leidt ertoe dat de gelijktijdige handshakes niet voor alle binnenkomende verbindingen kunnen plaatsvinden. Maar in ieder geval kan iemand de database betreden, zelfs als de belasting behoorlijk hoog is.
Roadmap
Wat zouden we in de toekomst willen zien in Odyssey? Wat zijn we bereid zelf te ontwikkelen en wat verwachten we van de gemeenschap?
Per augustus 2019.
Zo zag de roadmap van Odyssey eruit in augustus:
- We wilden SCRAM- en PAM-authenticatie.
- We wilden forward leesverzoeken naar standby.
- We zouden graag online-herstarten.
- En de mogelijkheid om een pauze op de server te nemen.
Half van deze roadmap is uitgevoerd, en niet door ons. En dat is goed. Laten we dus bespreken wat er nog overblijft en nog wat toevoegen.
? У нас есть реплики, которые без выполнения запросов будут просто греть воздух. Они нам необходимы для обеспечения failover и switchover. В случае проблем в одном из дата-центре хотелось бы их занять какой-то полезной работой. Потому что те же самые центральные процессоры, ту же самую память мы не можем сконфигурировать по-другому, потому что иначе не будет работать репликация.
In principe is er in Postgres, vanaf versie 10, de mogelijkheid om bij een verbinding ook session_attrs op te geven. In de verbinding kun je alle databasehosts opnoemen en aangeven waarom je naar de database gaat: om te schrijven of alleen om te lezen. En de driver kiest zelf de eerste host van de lijst die het het meest prettig vindt, die voldoet aan de vereisten van session_attrs.
Maar het probleem met deze aanpak is dat het de replicatievertraging niet controleert. Je kunt een replica hebben die achterloopt voor een tijd die onaanvaardbaar is voor je service. Om leesverzoeken op een replica volledig te ondersteunen, moeten we in feite in Odyssey de mogelijkheid ondersteunen om niet te functioneren wanneer lezen niet mogelijk is.
Odyssey moet af en toe de database raadplegen en het replicatieafstand tot de primaire vragen. En als dit een drempelwaarde heeft bereikt, geen nieuwe verzoeken naar de database toestaan, de klant vertellen dat ze opnieuw verbinding moeten maken en mogelijk een andere host moeten kiezen voor het uitvoeren van verzoeken. Dit zal de database helpen om sneller de replicatievertraging te herstellen en weer te kunnen reageren op verzoeken.
Het is moeilijk om termijnen voor implementatie te noemen, omdat het open source is. Maar ik hoop dat het niet 2,5 jaar duurt zoals bij collega's van PgBouncer. Deze functie zou ik graag in Odyssey willen zien.
U kunt een prepared statement nu op twee manieren aanmaken. Ten eerste kunt u de SQL-opdracht uitvoeren, namelijk 'prepared'. Om deze SQL-opdracht te begrijpen, moeten we leren om SQL aan de kant van Bouncer te begrijpen. Dit zou een overkill zijn, omdat we een volledige parser nodig hebben. We kunnen niet elke SQL-opdracht parseren.
Maar er is een prepared statement op het niveau van het berichtenprotocol op proto3. En dat is waar de informatie over het creëren van een prepared statement in gestructureerde vorm binnenkomt. We zouden kunnen ondersteunen dat we begrijpen dat de klant op een bepaalde serververbinding heeft gevraagd om prepared statements aan te maken. En zelfs als de transactie is gesloten, moeten we de connectiviteit tussen server en cliënt blijven ondersteunen.
Maar hier ontstaat een discrepantie in de dialoog, omdat iemand zegt dat we moeten begrijpen welke specifieke prepared statements de klant heeft aangemaakt en de serververbinding moeten scheiden tussen alle cliënten die deze serververbinding hebben aangemaakt, dat wil zeggen, die zo'n prepared statement hebben aangemaakt.
Andres Freund zei dat als er een klant bij je is gekomen die deze prepared statement al in een andere serververbinding had aangemaakt, je die dan voor hem moet aanmaken. Maar het lijkt een beetje verkeerd om verzoeken in de database uit te voeren in plaats van de client, maar vanuit het perspectief van de ontwikkelaar die het protocol voor interactie met de database schrijft, zou het handig zijn als hij gewoon een netwerkverbinding krijgt waarin zo'n voorbereid verzoek zit.
En nog een functie die we moeten implementeren. We hebben momenteel monitoring die compatibel is met PgBouncer. We kunnen de gemiddelde uitvoeringstijd van een verzoek teruggeven. Maar de gemiddelde tijd is de gemiddelde temperatuur in het ziekenhuis: sommige zijn koud, sommige warm - gemiddeld is iedereen gezond. Dat is niet waar.
We moeten ondersteuning voor percentielen implementeren die aangeven dat er trage verzoeken zijn die middelen verbruiken, en de monitoring acceptabeler zouden maken.
Het belangrijkste is dat we versie 1.0 willen (versie 1.1 is al uitgekomen). Het probleem is dat Odyssey momenteel in versie 1.0rc is, dat wil zeggen release candidate. En alle problemen die ik heb opgesomd, zijn precies met die versie opgelost, behalve het geheugenlek.
Wat betekent versie 1.0 voor ons? We rollen Odyssey uit naar onze databases. Het werkt nu al op onze databases, maar wanneer het de mijlpaal van 1.000.000 verzoeken per seconde bereikt, kunnen we zeggen dat dit de releaseversie is en dat dit de versie is die we 1.0 kunnen noemen.
In de gemeenschap hebben enkele mensen gevraagd of er in versie 1.0 ook een pauze en SCRAM zouden komen. Maar dat zou betekenen dat we de volgende versie al in productie zouden moeten uitrollen, omdat zowel SCRAM als pauze nog niet zijn samengevoegd. Maar waarschijnlijk zal deze kwestie snel worden opgelost.
Ik wacht op jullie pull requests. En ik zou ook graag horen welke problemen jullie met Bouncer hebben. Laten we die bespreken. Misschien kunnen we bepaalde functies implementeren die jullie nodig hebben.
Dit was mijn deel, ik wil graag jullie horen. Dank jullie!
Vragen
Als ik mijn application_name instel, wordt deze dan correct doorgegeven, ook in transaction pooling in Odyssey?
In Odyssey of in Bouncer?
In Odyssey. In Bouncer wordt het doorgegeven.
We zullen de set maken.
En als mijn echte verbinding springt naar andere verbindingen, wordt deze dan doorgegeven?
We zullen een set maken van alle parameters die in de lijst staan. Ik kan niet zeggen of application_name in die lijst staat. Ik denk dat ik het daar heb gezien. We zullen alle dezelfde parameters instellen. Eén verzoek zal alles doen wat door de cliënt is ingesteld bij de opstart.
Dank je, Andrei, voor de presentatie! Goede presentatie! Ik ben blij dat Odyssey met elke minuut sneller en sneller ontwikkelt. Ik wens je veel succes. We hebben al contact met jullie opgenomen met het verzoek om multi data-source verbinding te hebben, zodat Odyssey gelijktijdig kan verbinden met verschillende databases, dat wil zeggen master-slave, en vervolgens automatisch na failover kan verbinden met een nieuwe master.
Ja, ik herinner me die discussie. Er zijn momenteel verschillende storages. Maar er is geen schakeling tussen hen. We moeten aan onze kant de server controleren of deze nog actief is en begrijpen dat er een failover heeft plaatsgevonden, wie pg_recovery zal aanroepen. Ik heb een standaardmethode om te begrijpen dat we niet op de master zijn gekomen. En we moeten op een of andere manier uit de fouten afleiden, of niet? De idee is interessant, het wordt besproken. Schrijf meer commentaren. Als je werkende handen hebt die C kennen, is dat geweldig.
De vraag naar schaling met replicaties is ook voor ons van belang, omdat we de adoptie van gerepliceerde clusters zo eenvoudig mogelijk willen maken voor applicatie-ontwikkelaars. We zouden hier echter graag meer toelichting over willen, namelijk hoe we dit exact moeten realiseren en hoe we dit goed kunnen doen.
De vraag gaat ook over de replicaties. Dus jullie hebben een master en verschillende replicaties. En het is duidelijk dat er minder verbindingen naar de replicatie gaan dan naar de master, omdat er verschillen kunnen zijn. Je zei dat de afwijkingen in gegevens zo groot kunnen zijn dat dit niet voldoet aan jullie bedrijfsvereisten en dat jullie de replicatie niet zullen gebruiken totdat deze weer gesynchroniseerd is. Als je daar echter lange tijd niet naartoe bent gegaan en dan weer begint te connecteren, zijn de benodigde gegevens misschien niet direct beschikbaar. Dat betekent dat als we constant verbinding maken met de master, de cache daar warm is, terwijl de cache in de replicatie iets achterloopt.
Ja, dat klopt. In pcache zullen de gegevensblokken die je wilt niet aanwezig zijn, in de echte cache zullen er geen informatie over de tabellen zijn die je wilt, in de plannen zullen er geen geparsed queries zijn, er zal helemaal niets zijn.
En wanneer je een cluster hebt en je voegt een nieuwe replicatie toe, dan is het aanvankelijk slecht, dat wil zeggen dat het zijn cache aan het opbouwen is.
Ik begrijp het idee. De juiste aanpak zou zijn om een klein percentage van de verzoeken eerst naar de replicatie te sturen, die de cache zou verhitten. Grof gezegd, we hebben de voorwaarde dat we niet meer dan 10 seconden achter mogen lopen op de master. En deze voorwaarde moet niet in één keer worden ingevoerd, maar geleidelijk voor sommige klanten.
Ja, het gewicht verhogen.
Dit is een goed idee. Maar we moeten eerst deze uitschakeling implementeren. Eerst moeten we onszelf uitschakelen, en dan denken we na over hoe we weer kunnen inschakelen. Dit is een geweldige functie om geleidelijk in te schakelen.
In nginx is er een dergelijke optie langzaam starten in het cluster voor de server. En hij verhoogt geleidelijk de belasting.
Ja, geweldig idee, we zullen het proberen wanneer we daar zijn.
Bron: habr.com
