PostgreSQL Connection Pooling:Del 2 – PgBouncer

Når det kommer til forbindelsespooling i PostgreSQL-verdenen, er PgBouncer nok den mest populære mulighed. Det er et meget simpelt værktøj, der gør præcis én ting - det sidder mellem databasen og klienterne og taler PostgreSQL-protokollen og emulerer en PostgreSQL-server. En klient opretter forbindelse til PgBouncer med nøjagtig den samme syntaks, som den ville bruge, når den oprettede forbindelse direkte til PostgreSQL – PgBouncer er stort set usynlig.

PgBouncer understøttes af næsten alle PostgreSQL DBaaS-leverandører og bruges i vid udstrækning på tværs af fællesskabet. I dette blogindlæg forklarer vi, hvordan PgBouncer fungerer, fordele og ulemper ved at bruge det, og hvordan man opsætter forbindelsespooleren. Hvis du gerne vil vide mere om forbindelsespooling generelt, eller undrer dig over, om det er det rigtige for din implementering, så tjek vores PostgreSQL Connection Pooling:Del 1 - Fordele og ulemper-indlæg.

Hvordan virker PgBouncer?

Når PgBouncer modtager en klientforbindelse, udfører den først godkendelse på vegne af PostgreSQL-serveren. PgBouncer understøtter alle de godkendelsesmekanismer, som PostgreSQL-serveren understøtter, inklusive en værtsbaseret adgangskonfiguration (bemærk:vi kan ikke dirigere replikeringsforbindelser gennem PgBouncer). Hvis der er angivet en adgangskode, kan godkendelsen udføres på to måder:

1. PgBouncer tjekker først userlist.txt-filen – denne fil specificerer et sæt (brugernavn, md5-krypterede adgangskoder) tuples. Hvis brugernavnet findes i denne fil, matches adgangskoden mod den givne værdi. Der er ikke oprettet forbindelse til PostgreSQL-serveren.
2. Hvis passthrough-godkendelse er konfigureret, og brugeren ikke findes i userslist.txt-filen, søger PgBouncer efter en auth_query. Den opretter forbindelse til PostgreSQL som en foruddefineret bruger (hvis adgangskode skal være til stede i userslist.txt-filen) og udfører godkendelsesforespørgslen for at finde brugerens adgangskode og matcher den med den angivne værdi.

Når godkendelsen lykkes:

1. PgBouncer søger efter en cachelagret forbindelse med den samme brugernavn+databasekombination.
2. Hvis der findes en cachelagret forbindelse, returnerer den forbindelsen til klienten.
3. Hvis en cachelagret forbindelse ikke findes, opretter den en ny forbindelse, forudsat at oprettelse af en ny forbindelse ikke gør det:
   • Øg antallet af forbindelser til> pool_size
   • Øg antallet af forbindelser fra klienten til> max_client_connections
   • Øg antallet af forbindelser til databasen til> max_db_connections
   • Øg antallet af forbindelser fra brugeren til> max_user_connections
4. Alle disse værdier kan defineres i PgBouncer-indstillingerne.
5. Hvis oprettelse af en ny forbindelse ville overtræde nogen af ​​indstillingerne, sætter PgBouncer forbindelsen i kø, indtil en ny kan oprettes, undtagen hvis den overtræder begrænsningen for max_client_connections.
   

   Bemærk – Timingen af ​​post-godkendelsestrin varierer en smule baseret på PgBouncer-tilstand. Under transaktions- eller erklæringspuljetilstand udføres post-godkendelsestrinnene kun, når klienten begynder at udføre en transaktion/udsagn. Vi diskuterer mere om pooling-tilstandene nedenfor.

6. Hvis den overtræder begrænsningen for max_client_connections, afbryder den forbindelsen.

Baseret på poolingen tilstand, venter PgBouncer på en mulighed for at returnere forbindelsen til databasen:

• I sessionspooling-tilstand returneres en forbindelse kun til poolen, når en klient lukker sessionen.
• I transaktionspooling-tilstand returneres en forbindelse kun til puljen, når en klient fuldfører en transaktion (typisk udføres enten en rollback eller en commit). Som følge heraf understøttes sessionsbaserede funktioner ikke i denne tilstand. Der er ingen garanti for, at to transaktioner kørte på den samme klient PgBouncer-forbindelse vil køre på den samme PgBouncer-serverforbindelse.
• I sætningspooling-tilstand returneres en forbindelse til puljen, så snart en sætning udføres. Her er autocommit altid slået til.

Før forbindelsen returneres tilbage til databasen, kører PgBouncer en nulstillingsforespørgsel for at fjerne al sessionsinformation – dette gør det sikkert at dele forbindelser mellem klienter. Det er muligt at konfigurere denne forespørgsel baseret på applikationens behov.

Transaktionspooling-tilstanden bruges oftest, selvom sessionspooling-tilstanden kan være nyttig til bestemte arbejdsbelastninger. Du kan læse mere om PgBouncer på deres Wiki-side.

Hvorfor vælge PgBouncer?

Der er mange grunde til, at PgBouncer er det mest populære valg, når det kommer til forbindelsespooling i PostgreSQL. Her er nogle af de bedste funktioner og fordele PgBouncer tilbyder:

• Pool-tilstande – Ved at give brugerne magten til at bestemme, hvornår en forbindelse returneres til poolen, er PgBouncer i stand til at understøtte en lang række brugssager. Og da denne opsætning er på et puljeniveau, kan du bruge transaktionstilstand (bedre ydeevne) til dine sædvanlige databaseforbindelser og kun sessionstilstand, når du har brug for funktioner som forberedte erklæringer!
• Nem opsætning og brug – PgBouncer er en af ​​de nemmeste PostgreSQL-forbindelsespoolere at konfigurere ud af boksen, og den kræver heller ingen kodeændringer på klientsiden.
• Passthrough-godkendelse – PgBouncer er en af ​​de få "middleware" forbindelsespoolere, der sikkert kan autentificere en bruger uden at have adgang til deres adgangskoder (i almindelig tekst eller krypteret form). Dette gør PgBouncer mere sikker og meget nemmere at vedligeholde – du behøver ikke opdatere PgBouncer, hver gang en bruger opdaterer deres adgangskode.
• Letvægt – Det er en enkelt proces, og alle kommandoer fra klienten og svar fra serveren passerer PgBouncer uden nogen form for behandling. Så det behøver ikke at 'se' hele indholdet på én gang, og bevarer derfor et meget lille hukommelsesfodaftryk.
• Skalerbarhed og ydeevne – Som vi vil diskutere mere detaljeret i den sidste del af vores serie, kan PgBouncer markant forbedre de transaktioner pr. sekund, som din PostgreSQL-server kan understøtte, og den skalerer meget godt til et meget stort antal klienter.

Hvad gør PgBouncer ikke?

PgBouncer, selvom det er en fantastisk forbindelsespooler, understøtter ikke automatisk belastningsbalancering eller høj tilgængelighed. Det anbefaler at bruge andre almindelige linux-værktøjer som HAProxy til at skabe en arkitektur, der understøtter disse funktioner.

Tag et kig på eksemplet på PostgreSQL-arkitekturen til belastningsbalanceret læsning nedenfor:

Bemærk – Masterknudepunktet (at alle disse slaver ville replikere fra) er ikke vist i diagrammet.

Sådan konfigurerer du PgBouncer

Hvis du har en ScaleGrid PostgreSQL-implementering, kan du konfigurere PgBouncer med nogle få klik. Gå til detaljeringsvisningen af ​​din PostgreSQL-klynge, og klik på PgBouncer-ikonet. Når du har valgt "Aktiver PgBouncer", vil du blive præsenteret for konfigurationsmuligheder for at tilpasse din pooling-tilstand og poolstørrelse - du kan acceptere standardindstillingerne (bare rolig, du kan ændre dem når som helst uden nedetid), og klik på Aktiver!

Og det er det! Du er klar til at gå.

Hvis du har en ikke-ScaleGrid-implementering, distribueres PgBouncer som en del af PostgreSQL-lageret og kan installeres ved hjælp af de respektive pakkeadministratorer. For mere detaljerede instruktioner, eller for at bygge fra kilden, kan du følge instruktionerne fra deres blog.

Når den er installeret, kræver PgBouncer kun, at du opsætter et par konfigurationsparametre for at komme op at køre:

1. En liste over (brugernavn, md5-krypteret adgangskode) til godkendelse af klienter eller en passthrough-godkendelsesopsætning for en mere sikker implementering.
2. Interfaces/IP:porte til at lytte efter indgående forbindelser.
3. Puljedefinitioner. En 'pool' er et navn, som klienter bruger som databasenavn, når de forbinder til PgBouncer - det kan tilknyttes en fuld forbindelsesstreng (vært, port, dbnavn og bruger). Den enkleste definition er af formen:
   * = host=
   Dette vil oprette dynamiske puljer for hver kombination af dbnavn+bruger og oprette forbindelse til den definerede vært ved hjælp af porten, dbnavnet og brugernavnet, som er angivet af brugeren.

Og det er det! Du kan være i gang meget hurtigt med PgBouncer. Der er dog mange flere indstillinger, som skal tunes til enhver produktionsdistribution – de er uden for rammerne af dette blogindlæg, men du kan læse mere om dem i denne PgBouncer-konfigurationsoversigt.

PgBouncer er dog ikke den eneste mulighed for PostgreSQL-forbindelsespooling – i vores næste indlæg vil vi diskutere Pgpool-II, som nok er den vigtigste konkurrent til PgBouncer. Hold øje med vores fjerde indlæg i denne firedelte serie, hvor vi sammenligner PgBouncer vs. Pgpool-II.