PostgreSQL Connection Pooling:Deel 2 – PgBouncer

Als het gaat om het poolen van verbindingen in de PostgreSQL-wereld, is PgBouncer waarschijnlijk de meest populaire optie. Het is een heel eenvoudig hulpprogramma dat precies één ding doet:het bevindt zich tussen de database en de clients en spreekt het PostgreSQL-protocol, dat een PostgreSQL-server emuleert. Een client maakt verbinding met PgBouncer met exact dezelfde syntaxis die hij zou gebruiken bij rechtstreekse verbinding met PostgreSQL - PgBouncer is in wezen onzichtbaar.

PgBouncer wordt ondersteund door bijna elke PostgreSQL DBaaS-leverancier en wordt veel gebruikt door de hele gemeenschap. In deze blogpost leggen we uit hoe PgBouncer werkt, de voor- en nadelen van het gebruik ervan en hoe je de verbindingspooler instelt. Als je meer wilt weten over pooling van verbindingen in het algemeen, of als je je afvraagt ​​of het geschikt is voor jouw implementatie, bekijk dan onze PostgreSQL Connection Pooling:Part 1 – Pros &Cons post.

Hoe werkt PgBouncer?

Als PgBouncer een clientverbinding ontvangt, voert het eerst authenticatie uit namens de PostgreSQL-server. PgBouncer ondersteunt alle authenticatiemechanismen die de PostgreSQL-server ondersteunt, inclusief een hostgebaseerde toegangsconfiguratie (opmerking:we kunnen geen replicatieverbindingen via PgBouncer routeren). Als er een wachtwoord is opgegeven, kan de authenticatie op twee manieren worden gedaan:

1. PgBouncer controleert eerst het bestand userslist.txt – dit bestand specificeert een set (gebruikersnaam, md5 versleutelde wachtwoorden) tupels. Als de gebruikersnaam in dit bestand bestaat, wordt het wachtwoord vergeleken met de opgegeven waarde. Er wordt geen verbinding gemaakt met de PostgreSQL-server.
2. Als passthrough-authenticatie is ingesteld en de gebruiker wordt niet gevonden in het bestand userslist.txt, zoekt PgBouncer naar een auth_query. Het maakt verbinding met PostgreSQL als een vooraf gedefinieerde gebruiker (wiens wachtwoord aanwezig moet zijn in het bestand userslist.txt) en voert de auth-query uit om het wachtwoord van de gebruiker te vinden en koppelt het aan de opgegeven waarde.

Zodra de authenticatie is gelukt:

1. PgBouncer controleert op een verbinding in de cache, met dezelfde combinatie gebruikersnaam+database.
2. Als een verbinding in de cache wordt gevonden, wordt de verbinding naar de client geretourneerd.
3. Als er geen verbinding in de cache wordt gevonden, wordt er een nieuwe verbinding gemaakt, op voorwaarde dat het maken van een nieuwe verbinding niet:
   • Verhoog het aantal verbindingen naar> pool_size
   • Verhoog het aantal verbindingen van de client naar> max_client_connections
   • Verhoog het aantal verbindingen met de database naar> max_db_connections
   • Verhoog het aantal verbindingen van de gebruiker naar> max_user_connections
4. Al deze waarden kunnen worden gedefinieerd in de PgBouncer-instellingen.
5. Als het maken van een nieuwe verbinding een van de instellingen zou schenden, zet PgBouncer de verbinding in de wachtrij totdat een nieuwe kan worden gemaakt, behalve als het de beperking max_client_connections schendt.
   

   Opmerking – De timing van de stappen na de authenticatie verschilt enigszins, afhankelijk van de PgBouncer-modus. In de transactie- of overzichtspoolingmodus worden de stappen na authenticatie alleen uitgevoerd wanneer de klant begint met het uitvoeren van een transactie/afschrift. We bespreken hieronder meer over de pooling-modi.

6. Als het de max_client_connections-beperking schendt, wordt de verbinding afgebroken.

Gebaseerd op de pooling modus, wacht PgBouncer op een mogelijkheid om de verbinding terug te brengen naar de database:

• In de modus voor sessiepooling wordt er alleen een verbinding met de pool hersteld wanneer een client de sessie sluit.
• In de transactiepoolmodus wordt er alleen een verbinding naar de pool teruggestuurd wanneer een klant een transactie voltooit (meestal wordt ofwel een rollback ofwel een vastlegging uitgevoerd). Als gevolg hiervan worden sessiegebaseerde functies niet ondersteund in deze modus. Er is geen garantie dat twee transacties die op dezelfde client PgBouncer-verbinding worden uitgevoerd, ook op dezelfde PgBouncer-serververbinding worden uitgevoerd.
• In de pooling-modus voor instructies wordt er een verbinding naar de pool teruggestuurd zodra een instructie wordt uitgevoerd. Hier staat automatisch vastleggen altijd aan.

Voordat de verbinding terug naar de database wordt gebracht, voert PgBouncer een reset-query uit om alle sessie-informatie te verwijderen - dit maakt het veilig om verbindingen tussen clients te delen. Het is mogelijk om deze query te configureren op basis van de behoeften van de applicatie.

De transactiepooling-modus wordt het vaakst gebruikt, hoewel de sessiepooling-modus nuttig kan zijn voor bepaalde workloads. Je kunt meer lezen over PgBouncer op hun Wiki-pagina.

Waarom kiezen voor PgBouncer?

Er zijn veel redenen waarom PgBouncer de meest populaire keuze is als het gaat om het poolen van verbindingen in PostgreSQL. Hier zijn enkele van de beste functies en voordelen die PgBouncer biedt:

• Poolingmodi – Door gebruikers de bevoegdheid te geven om te beslissen wanneer een verbinding wordt hersteld naar de pool, kan PgBouncer een breed scala aan gebruikssituaties ondersteunen. En aangezien deze instelling op poolniveau is, kunt u de transactiemodus (betere prestaties) gebruiken voor uw gebruikelijke databaseverbindingen en de sessiemodus alleen als u functies zoals voorbereide instructies nodig hebt!
• Eenvoudige installatie en gebruik – PgBouncer is een van de gemakkelijkste PostgreSQL-verbindingspoolers om kant-en-klaar in te stellen, en er zijn ook geen codewijzigingen aan de clientzijde vereist.
• Passthrough-authenticatie – PgBouncer is een van de weinige “middleware” verbindingspoolers die een gebruiker veilig kan authenticeren zonder toegang te hebben tot hun wachtwoorden (in platte tekst of gecodeerde vorm). Dit maakt PgBouncer veiliger en veel gemakkelijker te onderhouden - u hoeft PgBouncer niet elke keer bij te werken als een gebruiker zijn wachtwoord bijwerkt.
• Lichtgewicht - Het is een enkel proces en alle opdrachten van de client en reacties van de server passeren PgBouncer zonder enige verwerking. Het hoeft dus niet de volledige inhoud in één keer te 'zien' en behoudt daarom een ​​zeer kleine geheugenvoetafdruk.
• Schaalbaarheid en prestaties – Zoals we in het laatste deel van onze serie in meer detail zullen bespreken, kan PgBouncer de transacties per seconde die uw PostgreSQL-server kan ondersteunen aanzienlijk verbeteren, en het schaalt zeer goed naar een zeer groot aantal klanten.

Wat doet PgBouncer niet?

PgBouncer, hoewel een geweldige verbindingspooler, ondersteunt geen geautomatiseerde taakverdeling of hoge beschikbaarheid. Het raadt aan om andere veelgebruikte Linux-tools zoals HAProxy te gebruiken om een ​​architectuur te maken die deze functies wel ondersteunt.

Bekijk het voorbeeld van de PostgreSQL-architectuur voor load-balanced reads hieronder:

Opmerking:het hoofdknooppunt (dat al deze zou repliceren van) wordt niet weergegeven in het diagram.

PgBouncer instellen

Als je een ScaleGrid PostgreSQL-implementatie hebt, kun je PgBouncer met een paar klikken instellen. Ga naar de detailweergave van uw PostgreSQL-cluster en klik op het PgBouncer-pictogram. Zodra u "Enable PgBouncer" selecteert, krijgt u configuratie-opties te zien om uw pooling-modus en poolgrootte aan te passen - u kunt de standaardinstellingen accepteren (maak u geen zorgen, u kunt ze op elk moment wijzigen zonder downtime) en klik op Inschakelen!

En dat is alles! Je bent klaar om te gaan.

Als je een niet-ScaleGrid-implementatie hebt, wordt PgBouncer gedistribueerd als onderdeel van de PostgreSQL-repository en kan het worden geïnstalleerd met behulp van de respectieve pakketbeheerders. Voor meer gedetailleerde instructies of om vanaf de bron te bouwen, kun je de instructies van hun blog volgen.

Na installatie hoeft u voor PgBouncer slechts een paar configuratieparameters in te stellen om aan de slag te gaan:

1. Een lijst met (gebruikersnaam, md5-gecodeerd wachtwoord) om clients te verifiëren of een passthrough-authenticatieconfiguratie voor een veiligere implementatie.
2. Interfaces/IP:ports om te luisteren naar inkomende verbindingen.
3. Zwembaddefinities. Een 'pool' is een naam die clients gebruiken als databasenaam bij het verbinden met PgBouncer - het kan worden toegewezen aan een volledige verbindingsreeks (host, poort, dbnaam en gebruiker). De eenvoudigste definitie is van de vorm:
   * = host=
   Hiermee worden dynamische pools gemaakt voor elke dbname+user-combinatie en wordt verbinding gemaakt met de gedefinieerde host met behulp van de poort, dbname en gebruikersnaam die door de gebruiker zijn opgegeven.

En dat is het! U kunt heel snel aan de slag met PgBouncer. Er zijn echter veel meer instellingen die moeten worden aangepast voor elke productiedistributie - die vallen buiten het bestek van deze blogpost, maar u kunt er meer over lezen in dit PgBouncer-configuratieoverzicht.

PgBouncer is echter niet de enige optie voor PostgreSQL-verbindingspooling - in ons volgende bericht zullen we Pgpool-II bespreken, wat waarschijnlijk de belangrijkste concurrent van PgBouncer. Houd ons in de gaten voor onze vierde post in deze vierdelige serie waarin we PgBouncer vergelijken met Pgpool-II.