PostgreSQL Connection Pooling:Del 2 – PgBouncer

När det kommer till anslutningspooling i PostgreSQL-världen är PgBouncer förmodligen det mest populära alternativet. Det är ett väldigt enkelt verktyg som gör exakt en sak – det sitter mellan databasen och klienterna och talar PostgreSQL-protokollet, som emulerar en PostgreSQL-server. En klient ansluter till PgBouncer med exakt samma syntax som den skulle använda när den ansluter direkt till PostgreSQL – PgBouncer är i princip osynlig.

PgBouncer stöds av nästan alla PostgreSQL DBaaS-leverantörer och används flitigt i hela gemenskapen. I det här blogginlägget kommer vi att förklara hur PgBouncer fungerar, fördelarna och nackdelarna med att använda den och hur man ställer in anslutningspoolern. Om du vill veta mer om anslutningspooling i allmänhet, eller undrar om det är rätt för din implementering, kolla in vårt PostgreSQL Connection Pooling:Del 1 – Fördelar och nackdelar.

Hur fungerar PgBouncer?

När PgBouncer tar emot en klientanslutning, utför den först autentisering på uppdrag av PostgreSQL-servern. PgBouncer stöder alla autentiseringsmekanismer som PostgreSQL-servern stöder, inklusive en värdbaserad åtkomstkonfiguration (notera:vi kan inte dirigera replikeringsanslutningar genom PgBouncer). Om ett lösenord tillhandahålls kan autentiseringen göras på två sätt:

1. PgBouncer kontrollerar först filen userslist.txt – den här filen anger en uppsättning (användarnamn, md5-krypterade lösenord) tupler. Om användarnamnet finns i den här filen matchas lösenordet mot det angivna värdet. Ingen anslutning till PostgreSQL-servern görs.
2. Om passthrough-autentisering är inställd och användaren inte hittas i filen userslist.txt, söker PgBouncer efter en auth_query. Den ansluter till PostgreSQL som en fördefinierad användare (vars lösenord måste finnas i filen userslist.txt) och kör autentiseringsfrågan för att hitta användarens lösenord och matchar det med det angivna värdet.

När autentiseringen har lyckats:

1. PgBouncer söker efter en cachad anslutning, med samma användarnamn+databaskombination.
2. Om en cachad anslutning hittas returnerar den anslutningen till klienten.
3. Om en cachad anslutning inte hittas, skapar den en ny anslutning, förutsatt att skapa en ny anslutning inte gör det:
   • Öka antalet anslutningar till> pool_size
   • Öka antalet anslutningar från klienten till> max_client_connections
   • Öka antalet anslutningar till databasen till> max_db_connections
   • Öka antalet anslutningar från användaren till> max_user_connections
4. Alla dessa värden kan definieras i PgBouncer-inställningarna.
5. Om att skapa en ny anslutning skulle bryta mot någon av inställningarna ställer PgBouncer anslutningen i kö tills en ny kan skapas, förutom om den bryter mot begränsningen för max_client_connections.
   

   Obs – Tidpunkten för efterautentiseringssteg skiljer sig något beroende på PgBouncer-läget. Under transaktions- eller uttalandepoolningsläge exekveras stegen efter autentisering endast när klienten börjar utföra en transaktion/utlåtande. Vi diskuterar mer om poolningslägena nedan.

6. Om den bryter mot begränsningen för max_client_connections avbryter den anslutningen.

Baserat på poolningen läge, väntar PgBouncer på en möjlighet att återställa anslutningen till databasen:

• I sessionspoolningsläge återgår en anslutning till poolen endast när en klient stänger sessionen.
• I transaktionspoolningsläge återgår en anslutning till poolen endast när en klient slutför en transaktion (vanligtvis utförs antingen en återställning eller en commit). Som ett resultat av detta stöds inte sessionsbaserade funktioner i det här läget. Det finns ingen garanti för att två transaktioner som körs på samma klient PgBouncer-anslutning kommer att köras på samma PgBouncer-serveranslutning.
• I satspoolningsläge återgår en anslutning till poolen så snart en sats exekveras. Här är autocommit alltid på.

Innan anslutningen returneras till databasen, kör PgBouncer en återställningsfråga för att ta bort all sessionsinformation – detta gör det säkert att dela anslutningar mellan klienter. Det är möjligt att konfigurera denna fråga baserat på applikationens behov.

Transaktionspoolningsläget används oftast, även om sessionspoolningsläget kan vara användbart för särskilda arbetsbelastningar. Du kan läsa mer om PgBouncer på deras Wiki-sida.

Varför välja PgBouncer?

Det finns många anledningar till att PgBouncer är det mest populära valet när det kommer till anslutningspoolning i PostgreSQL. Här är några av de bästa funktionerna och proffsen som PgBouncer erbjuder:

• Poolinglägen – Genom att ge användarna makten att bestämma när en anslutning återförs till poolen, kan PgBouncer stödja ett stort antal användningsfall. Och eftersom den här inställningen är på poolnivå kan du använda transaktionsläge (bättre prestanda) för dina vanliga databasanslutningar och sessionsläge endast när du behöver funktioner som förberedda uttalanden!
• Enkel installation och användning – PgBouncer är en av de enklaste PostgreSQL-anslutningspoolarna att installera direkt, och den kräver inte heller några kodändringar på klientsidan.
• Passthrough-autentisering – PgBouncer är en av få "mellanprogram"-anslutningspoolare som säkert kan autentisera en användare utan att ha tillgång till deras lösenord (i klartext eller krypterad form). Detta gör PgBouncer säkrare och mycket enklare att underhålla – du behöver inte uppdatera PgBouncer varje gång en användare uppdaterar sitt lösenord.
• Lättvikts – Det är en enda process, och alla kommandon från klienten och svar från servern passerar PgBouncer utan någon bearbetning. Så den behöver inte "se" hela innehållet på en gång, och har därför ett mycket litet minnesfotavtryck.
• Skalbarhet och prestanda – Som vi kommer att diskutera mer i detalj i den sista delen av vår serie, kan PgBouncer avsevärt förbättra transaktionerna per sekund som din PostgreSQL-server kan stödja, och den skalas mycket bra till ett mycket stort antal klienter.

Vad gör inte PgBouncer?

PgBouncer, även om den är en bra anslutningspoolare, stöder inte automatisk lastbalansering eller hög tillgänglighet. Det rekommenderar att du använder andra vanliga linuxverktyg som HAProxy för att skapa en arkitektur som stöder dessa funktioner.

Ta en titt på exempel på PostgreSQL-arkitekturen för belastningsbalanserad läsning nedan:

Obs – Masternoden (att alla dessa slavar skulle replikera från) visas inte i diagrammet.

Så ställer du in PgBouncer

Om du har en ScaleGrid PostgreSQL-distribution kan du ställa in PgBouncer med några få klick. Gå till detaljvyn för ditt PostgreSQL-kluster och klicka på PgBouncer-ikonen. När du väljer "Aktivera PgBouncer" kommer du att presenteras med konfigurationsalternativ för att anpassa ditt poolläge och poolstorlek – du kan acceptera standardinställningarna (oroa dig inte, du kan ändra dem när som helst utan driftstopp) och klicka på Aktivera!

Och det är allt! Du är bra att gå.

Om du har en icke-ScaleGrid-distribution distribueras PgBouncer som en del av PostgreSQL-förrådet och kan installeras med respektive pakethanterare. För mer detaljerade instruktioner, eller för att bygga från källa, kan du följa instruktionerna från deras blogg.

När PgBouncer har installerats behöver du bara ställa in några konfigurationsparametrar för att komma igång:

1. En lista med (användarnamn, md5-krypterat lösenord) för att autentisera klienter eller en passthrough-autentiseringsinställning för en säkrare distribution.
2. Gränssnitt/IP:portar för att lyssna efter inkommande anslutningar.
3. Pooldefinitioner. En "pool" är ett namn som klienter använder som ett databasnamn när de ansluter till PgBouncer - det kan mappas till en fullständig anslutningssträng (värd, port, dbname och användare). Den enklaste definitionen är av formen:
   * = host=
   Detta kommer att skapa dynamiska pooler för varje kombination av dbname+användare och ansluta till den definierade värden med hjälp av porten, dbname och användarnamn som tillhandahålls av användaren.

Och det är det! Du kan vara igång väldigt snabbt med PgBouncer. Det finns dock många fler inställningar som måste ställas in för all produktionsdistribution – de ligger utanför ramen för detta blogginlägg, men du kan läsa mer om dem i denna PgBouncer-konfigurationsöversikt.

PgBouncer är dock inte det enda alternativet för PostgreSQL-anslutningspoolning – i vårt nästa inlägg kommer vi att diskutera Pgpool-II, som förmodligen är den viktigaste konkurrent till PgBouncer. Håll utkik efter vårt fjärde inlägg i denna fyradelade serie där vi jämför PgBouncer vs. Pgpool-II.