Connection pooling met PgBouncer

Om het probleem van 'te veel verbindingen' op te lossen, gebruiken we een verbindingspooler. Voor PostgreSQL is PgBouncer een populaire en efficiënte keuze.

PgBouncer is een lichtgewicht externe proxy die tussen je toepassing en je PostgreSQL-database staat. De belangrijkste taak ervan is het beheren en hergebruiken van databaseverbindingen.

Zie PgBouncer als een poortwachter met een voorraad al geopende verbindingen met PostgreSQL. Wanneer een toepassing met de database moet communiceren:

1. De toepassing maakt verbinding met PgBouncer (niet rechtstreeks met PostgreSQL).
2. PgBouncer controleert zijn pool op een beschikbare verbinding met PostgreSQL.
3. Als er een beschikbaar is, geeft PgBouncer deze aan de toepassing.
4. Wanneer de toepassing klaar is, neemt PgBouncer de verbinding terug en plaatst deze terug in de pool, zodat een andere client deze opnieuw kan gebruiken.

PgBouncer biedt verschillende poolingmodi voor uiteenlopende behoeften van toepassingen:

• Sessiepooling: (pool_mode = session) De meest gebruikte modus. Een verbinding wordt gedurende de hele sessie aan een client toegewezen en pas teruggegeven aan de pool wanneer de client de verbinding verbreekt.
• Transactiepooling: (pool_mode = transaction) Een verbinding wordt toegewezen voor de duur van één transactie. Nadat de transactie is vastgelegd of teruggedraaid, wordt de verbinding onmiddellijk teruggegeven aan de pool.
• Statementpooling: (pool_mode = statement) De meest agressieve modus. Een verbinding wordt na elk afzonderlijk statement teruggegeven aan de pool. Gebruik deze modus zorgvuldig, omdat transacties die uit meerdere statements bestaan hierdoor kunnen worden verbroken.

Het gedrag van PgBouncer wordt bepaald door het configuratiebestand, meestal pgbouncer.ini. Dit zijn enkele belangrijke secties en parameters:

• [databases]: bepaalt met welke PostgreSQL-databases PgBouncer verbinding kan maken.
• [pgbouncer]: bevat algemene instellingen voor PgBouncer zelf.

PgBouncer verzorgt zelf de verificatie van clients die ermee verbinding maken. Het gebruikt niet rechtstreeks de verificatie van PostgreSQL. Veelgebruikte methoden zijn:

• auth_file: een eenvoudig tekstbestand (bijvoorbeeld users.txt) met gebruikersnamen en hun met MD5 gehashte wachtwoorden.
• auth_query: PgBouncer bevraagt de PostgreSQL-database zelf om gebruikers te verifiëren. Dit is flexibeler voor dynamisch gebruikersbeheer.

Zorg ervoor dat de gebruikers die verbinding maken met PgBouncer ook in uw PostgreSQL-database bestaan en over de benodigde rechten beschikken.

Zodra PgBouncer actief is, maken uw toepassingen verbinding met de luisterpoort van PgBouncer (bijvoorbeeld 6432) in plaats van met de standaardpoort van PostgreSQL (5432).

De verbindingsreeks van de toepassing verwijst dan naar de host en poort van PgBouncer, maar ziet er verder vergelijkbaar uit met een rechtstreekse PostgreSQL-verbinding.

PgBouncer implementeren biedt verschillende belangrijke voordelen voor de prestaties en stabiliteit van databases:

• Minder overhead: voorkomt de kosten van het tot stand brengen van nieuwe verbindingen voor elk clientverzoek.
• Betere stabiliteit: beschermt PostgreSQL tegen overbelasting door te veel clientverbindingen.
• Snellere verbindingen: toepassingen krijgen vrijwel onmiddellijk een verbinding uit de pool.
• Flexibel onderhoud: in de transactiepoolingmodus kunt u PostgreSQL opnieuw starten zonder actieve clientverbindingen te verbreken, omdat PgBouncer deze vasthoudt.

U heeft geleerd dat verbindingspooling, specifiek met PgBouncer, essentieel is om databaseverbindingen efficiënt te beheren.

• Het werkt als een proxy en hergebruikt verbindingen om overhead te verminderen.
• Verschillende poolingmodi (sessie, transactie, statement) bieden flexibiliteit.
• De configuratie omvat pgbouncer.ini en gebruikersbeheer.
• De voordelen zijn betere prestaties, meer stabiliteit en snellere verbindingstijden.

Ontdek hierna hoe u de parameters van PgBouncer nauwkeurig afstemt en het integreert in een omgeving met hoge beschikbaarheid.