Strategi för anslutningspoolning med hjälp av PgBouncer i Azure Database for PostgreSQL – flexibel server

Den här artikeln innehåller strategisk vägledning för att välja en mekanism för anslutningspooler för dina Azure Database for PostgreSQL flexibla servrar.

Introduction

När du använder en Azure Database for PostgreSQL flexibel server skapar du en anslutning till databasen genom att upprätta en kommunikationskanal mellan klientprogrammet och servern. Den här kanalen hanterar data, kör frågor och initierar transaktioner. När du har upprättat anslutningen kan klientprogrammet skicka kommandon till servern och ta emot svar. Att skapa en ny anslutning för varje åtgärd kan dock orsaka prestandaproblem för verksamhetskritiska program. Varje gång du skapar en ny anslutning startar Azure Database for PostgreSQL en ny process med hjälp av postmasterprocessen, som förbrukar mer resurser.

Du kan lösa problemet genom att använda anslutningspooler för att skapa en cache med anslutningar som Azure Database for PostgreSQL kan återanvända. När ett program eller en klient begär en anslutning kommer den från anslutningspoolen. När sessionen eller transaktionen har slutförts går anslutningen tillbaka till poolen för återanvändning. Genom att återanvända anslutningar minskar du resursanvändningen och förbättrar prestandan.

Även om det finns olika verktyg för anslutningspooler beskrivs olika strategier för att använda anslutningspooler med hjälp av PgBouncer i det här avsnittet.

Vad är PgBouncer?

PgBouncer är en effektiv anslutningspool som utformats för PostgreSQL. Det minskar bearbetningstiden och optimerar resursanvändningen när du hanterar flera klientanslutningar till en eller flera databaser. PgBouncer erbjuder tre distinkta poollägen för anslutningsrotation:

• Sessionspool: Den här metoden tilldelar en serveranslutning till klientprogrammet under hela varaktigheten för klientens anslutning. När klientprogrammet kopplas från returnerar PgBouncer omedelbart serveranslutningen tillbaka till poolen. Sessionspooler är standardläget i open-source PgBouncer. Mer information finns i PgBouncer-konfiguration.
• Transaktionspool: Med transaktionspooler är en serveranslutning dedikerad till klientprogrammet under en transaktion. När transaktionen har slutförts släpper PgBouncer serveranslutningen, vilket gör den tillgänglig igen i poolen. Transaktionspoolning är standardläget i Azure Database for PostgreSQLs inbyggda PgBouncer, och det stöder inte preparerade transaktioner.
• Instruktionspool: I instruktionspooler allokeras en serveranslutning till klientprogrammet för varje enskild instruktion. När instruktionen är klar returneras serveranslutningen till anslutningspoolen. Transaktioner med flera satser stöds inte i det här läget.

Du kan använda PgBouncer i tre distinkta användningsmönster:

• Distribution av PgBouncer och programsamlokalisering
• Programoberoende centraliserade PgBouncer-distributioner
• Inbyggd PgBouncer och databasdriftsättning

Var och en av dessa mönster har sina egna fördelar och nackdelar.

Driftsättning av PgBouncer och samlokalisering av applikationer

När du använder den här metoden distribuerar du PgBouncer på samma server där programmet finns. Du kan distribuera programmet och PgBouncer på traditionella virtuella datorer eller inom en mikrotjänstbaserad arkitektur, enligt följande:

PgBouncer distribuerad i en virtuell programdator

Om ditt program körs på en virtuell Azure-dator kan du konfigurera PgBouncer på samma virtuella dator. Information om hur du installerar och konfigurerar PgBouncer som en anslutningspoolproxy med din Azure Database for PostgreSQL flexibla server finns i Steg för att installera och konfigurera PgBouncer-anslutningspoolproxy.

Att distribuera PgBouncer på en programserver kan ge flera fördelar, särskilt när du arbetar med flexibla serverdatabaser i Azure Database for PostgreSQL. Några av de viktigaste fördelarna och begränsningarna med den här distributionsmetoden är:

Fördelar:

• Kortare svarstid: Genom att distribuera PgBouncer på samma virtuella programdator är kommunikationen mellan det primära programmet och anslutningspoolen effektiv på grund av deras närhet. Distribution av PgBouncer på den virtuella programdatorn minimerar svarstiden och säkerställer smidiga och snabba interaktioner.
• Förbättrad säkerhet:PgBouncer kan fungera som en säker mellanhand mellan programmet och databasen, vilket ger ett extra säkerhetslager. Det kan framtvinga autentisering och kryptering, vilket säkerställer att endast auktoriserade klienter kan komma åt databasen.

Att distribuera PgBouncer på en programserver ger en mer effektiv, säker och skalbar metod för att hantera anslutningar till Azure Database for PostgreSQL– flexibla serverdatabaser, vilket förbättrar programmets prestanda och tillförlitlighet.

Limitations:

• Enskild felpunkt: Om du distribuerar PgBouncer som en enda instans på programservern blir det en potentiell felpunkt. Om PgBouncer-instansen slutar fungera kan den störa hela databasanslutningspoolen, vilket orsakar driftstopp för programmet. För att minimera den här felpunkten konfigurerar du flera PgBouncer-instanser bakom en lastbalanserare för hög tillgänglighet.
• Begränsad skalbarhet: PgBouncer-skalbarhet beror på kapaciteten på den server där den distribueras. Om programservern når anslutningsgränsen kan PgBouncer bli en flaskhals, vilket begränsar möjligheten att skala programmet. Du kan behöva distribuera anslutningsbelastningen över flera PgBouncer-instanser eller överväga alternativa lösningar som anslutningspooler på programnivå.
• Konfigurationskomplexitet: Konfiguration och finjustering av PgBouncer kan vara komplext, särskilt när du överväger faktorer som anslutningsgränser, poolstorlek och belastningsutjämning. Administratörer måste noggrant justera PgBouncer-konfigurationen för att matcha programmets krav och säkerställa optimal prestanda och stabilitet.

Väg dessa begränsningar mot fördelarna och utvärdera om PgBouncer är rätt val för din specifika program- och databaskonfiguration.

PgBouncer driftsatt som en AKS-sidecar

Du kan använda PgBouncer som en sidovagnscontainer om ditt program är containeriserat och körs på Azure Kubernetes Service (AKS), Azure Container Instance (ACI), Azure Container Apps (ACA), eller Azure Red Hat OpenShift (ARO). Sidovagnsmönstret hämtar sin inspiration från konceptet med en sidovagn som fäster vid en motorcykel. En hjälpkontainer, kallad sidecar-container, är knuten till en överordnad applikation. Det här mönstret berikar det överordnade programmet genom att utöka dess funktioner och leverera kompletterande support.

När du distribuerar PgBouncer i en AKS-sidovagn kopplas programmets och sidovagnens livscykelr samman och delar resurser som värdnamn och nätverk för att effektivt använda resurser. PgBouncer-sidecar-containern körs sida vid sida med applikationscontainern i samma podd i Azure Kubernetes Service (AKS) med en 1:1-mappning och fungerar som en proxy för anslutningspoolning för Azure Database for PostgreSQL Flexible Server-instanser.

Microsoft tillhandahåller en PgBouncer-sidecar-proxyavbildning i Microsofts containerregister.

Mer information finns i det här avsnittet.

Några av de viktigaste fördelarna och begränsningarna med den här distributionsmetoden är:

Fördelar:

• Kortare svarstid: Genom att distribuera PgBouncer som en AKS-sidovagn är kommunikationen mellan det primära programmet och anslutningspoolen sömlös och effektiv på grund av deras närhet. Att köra PgBouncer som en AKS-sidovagn minimerar latensen och säkerställer smidiga och snabba interaktioner.
• Förenklad hantering och distribution: Den snäva kopplingen mellan PgBouncer och programcontainern förenklar hanterings- och distributionsprocessen. Båda komponenterna är tätt integrerade, så du kan administrera dem enklare och samordna dem sömlöst.
• Hög tillgänglighet och anslutningsresiliens: Om ett fel i en applikationscontainer uppstår eller om den startas om, följer PgBouncer-sidecar-containern tätt efter, vilket säkerställer hög tillgänglighet. Den här konfigurationen garanterar anslutningsåterhämtning och bibehåller förutsägbara prestanda även under redundansväxlingar, vilket bidrar till ett tillförlitligt och robust system.

Genom att betrakta PgBouncer som en AKS-sidovagn kan du använda dessa fördelar för att förbättra programmets prestanda, effektivisera hanteringen och säkerställa kontinuerlig tillgänglighet för anslutningspoolen.

Limitations:

• Problem med anslutningsprestanda: Storskaliga applikationer som använder tusentals poddar, där var och en kör sidecar-versionen av PgBouncer, kan stöta på problem relaterade till uttömning av databasanslutningar. Den här situationen kan leda till prestandaförsämring och avbrott i tjänsten. Att distribuera en PgBouncer som sidovagn för varje pod ökar antalet samtidiga anslutningar till databasservern, vilket kan överskrida dess kapacitet. Därför kan databasen ha svårt att hantera den stora mängden inkommande anslutningar, vilket leder till prestandaproblem som ökade svarstider eller till och med avbrott i tjänsten.
• Komplex distribution: Användningen av sidovagnsmönstret ger en komplexitetsnivå i distributionsprocessen, eftersom det innebär att två containrar körs i samma podd. Den här komplexiteten kan potentiellt komplicera felsöknings- och felsökningsaktiviteter, vilket kräver extra arbete för att identifiera och lösa problem.
• Skalningsutmaningar: Sidovagnsmönstret kanske inte är det perfekta valet för program som kräver hög skalbarhet. Införandet av en sidovagnscontainer kan medföra fler resurskrav, vilket kan begränsa antalet poddar som du effektivt kan skapa och hantera.

När du överväger det här sidovagnsmönstret bör du noggrant utvärdera kompromisserna mellan kraven på distributionskomplexitet och skalbarhet för att fastställa den lämpligaste metoden för ditt specifika programscenario.

Programoberoende – centraliserad PgBouncer-distribution

När du använder den här metoden distribuerar du PgBouncer som en centraliserad tjänst som är oberoende av programmet. Du kan distribuera PgBouncer-tjänsten på traditionella virtuella datorer eller inom en mikrotjänstbaserad arkitektur, enligt beskrivningen i följande avsnitt:

PgBouncer distribuerad i en virtuell Ubuntu-dator bakom Azure Load Balancer

Konfigurera PgBouncer-anslutningsproxyn mellan program- och databasskiktet bakom en Azure Load Balancer, enligt följande bild. I det här mönstret distribuerar du flera PgBouncer-instanser bakom en lastbalanserare som en tjänst för att minimera en enskild felpunkt. Det här mönstret är också lämpligt i scenarier där programmet körs på en hanterad tjänst som Azure App Services eller Azure Functions och ansluter till PgBouncer-tjänsten för enkel integrering med din befintliga infrastruktur.

Information om hur du installerar och konfigurerar PgBouncer-anslutningspoolproxy med Azure Database for PostgreSQL flexibla servrar finns i Steg för att installera och konfigurera PgBouncer-anslutningspoolproxy.

Några av de viktigaste fördelarna och begränsningarna med den här distributionsmetoden är:

Fördelar:

• Tar bort en enskild felpunkt: Programanslutningen påverkas inte av felet för en enda virtuell PgBouncer-dator, eftersom flera PgBouncer-instanser ligger bakom Azure Load Balancer.
• Sömlös integrering med Managed Services: Om ditt program finns på en hanterad tjänstplattform, till exempel Azure App Services eller Azure Functions, kan du enkelt integrera PgBouncer på en virtuell dator med din befintliga infrastruktur.
• Förenklad installation på en virtuell Azure-dator: Om du redan kör programmet på en virtuell Azure-dator är det enkelt att konfigurera PgBouncer på samma virtuella dator. När du distribuerar PgBouncer på den virtuella datorn ser du till att PgBouncer distribueras nära ditt program, vilket minimerar nätverksfördröjningen och maximerar prestandan.
• Icke-påträngande konfiguration: Genom att distribuera PgBouncer på en virtuell dator kan du undvika att ändra parametrar på din Azure Database for PostgreSQL flexibla servern. Den här konfigurationen är användbar när du vill konfigurera PgBouncer på en Azure Database for PostgreSQL flexibel server. Om du till exempel ändrar parametern SSLMODE till "obligatorisk" på en Azure Database for PostgreSQL flexibel server kan vissa program som förlitar sig på SSLMODE=FALSE misslyckas. När du distribuerar PgBouncer på en separat virtuell dator kan du behålla standardserverkonfigurationen medan du fortfarande använder PgBouncer-fördelarna.

Genom att överväga dessa fördelar erbjuder distribution av PgBouncer på en virtuell dator en bekväm och effektiv lösning för att förbättra prestanda och kompatibilitet för ditt program som körs i Azure-infrastrukturen.

Limitations:

• Hanteringskostnader: När du installerar PgBouncer på en virtuell dator kan du ha hanteringskostnader för att hantera flera konfigurationsfiler. Den här konfigurationen gör det svårt att hantera versionsuppgraderingar, nya versioner och produktuppdateringar.
• Funktionsparitet: Om du migrerar från traditionell PostgreSQL till en Azure Database for PostgreSQL flexibel server och använder PgBouncer kan det finnas vissa funktionsluckor. Till exempel saknas md5-stöd i Azure Database for PostgreSQL.

Centraliserad PgBouncer distribuerad som en tjänst i AKS

Om du arbetar med mycket skalbara och stora containerbaserade distributioner på Azure Kubernetes Service (AKS), som består av hundratals poddar eller i situationer där flera program behöver ansluta till en delad databas, använder du PgBouncer som en fristående tjänst i stället för en sidovagnscontainer.

Genom att använda PgBouncer som en separat tjänst kan du effektivt hantera anslutningspooler för dina program i större skala. Den här metoden centraliserar funktionerna för anslutningspooler, vilket gör att flera program kan ansluta till samma databasresurs samtidigt som optimal prestanda och resursanvändning bibehålls.

Använd PgBouncer-sidecar-proxyavbildningen som publicerats i Microsofts containerregister för att skapa och distribuera en tjänst.

Några av de viktigaste fördelarna och begränsningarna med den här distributionsmetoden är:

Fördelar:

• Förbättrad tillförlitlighet: När du distribuerar PgBouncer som en fristående tjänst kan du konfigurera den på ett sätt med hög tillgänglighet. Den här konfigurationen förbättrar den övergripande tillförlitligheten för infrastrukturen för anslutningspooler, vilket säkerställer kontinuerlig tillgänglighet även vid fel eller störningar.
• Optimal resursanvändning: Om programmet eller databasservern har begränsade resurser kan en separat dator som är dedikerad till att köra PgBouncer-tjänsten vara fördelaktig. Genom att distribuera PgBouncer på en dator med gott om resurser säkerställer du optimala prestanda och förhindrar problem med resurskonkurrens.
• Centraliserad anslutningshantering: När centraliserad hantering av databasanslutningar är ett krav ger en fristående PgBouncer-tjänst en mer effektiv metod. Genom att konsolidera uppgifter för anslutningshantering i en centraliserad tjänst kan du effektivt övervaka och kontrollera databasanslutningar i flera program, förenkla administrationen och säkerställa konsekvens.

Genom att betrakta PgBouncer som en fristående tjänst i AKS kan du använda dessa fördelar för att få bättre tillförlitlighet, resurseffektivitet och centraliserad hantering av databasanslutningar.

Limitations:

• Ökad N/W-svarstid: När du distribuerar PgBouncer som en fristående tjänst bör du överväga att införa mer svarstid. Den här svarstiden beror på att programmet och PgBouncer-tjänsten måste skicka anslutningar via nätverket. Utvärdera svarstidskraven för ditt program och överväg kompromisserna mellan centraliserad anslutningshantering och potentiella svarstidsproblem.

Även om PgBouncer som körs som en fristående tjänst erbjuder fördelar som centraliserad hantering och resursoptimering, utvärderar du effekten av potentiella svarstider på programmets prestanda för att säkerställa att den överensstämmer med dina specifika krav.

Inbyggd PgBouncer i Azure Database för PostgreSQL

Azure Database for PostgreSQL erbjuder PgBouncer som en inbyggd lösning för anslutningspooler. Du kan aktivera den här valfria tjänsten per databasserver. PgBouncer körs på samma virtuella dator som Azure Database for PostgreSQL flexibel server. När antalet anslutningar ökar över några hundra tusen kan Azure Database for PostgreSQL stöta på resursbegränsningar. I sådana fall kan inbyggda PgBouncer ge en betydande fördel genom att förbättra hanteringen av inaktiva och kortvariga anslutningar på databasservern.

Information om hur du aktiverar och konfigurerar PgBouncer-anslutningspooler i Azure Database for PostgreSQL finns i PgBouncer i Azure Database for PostgreSQL flexibel server.

Några av de viktigaste fördelarna och begränsningarna med den här distributionsmetoden är:

Fördelar:

• Sömlös konfiguration: Genom att använda den inbyggda PgBouncer i din Azure Database for PostgreSQL flexibla server behöver du ingen separat installation eller komplex installation. Du kan enkelt konfigurera den direkt från parametrarna, vilket ger en problemfri upplevelse.
• Bekvämlighet för hanterad tjänst: Som en hanterad tjänst kan du dra nytta av fördelarna med andra Azure hanterade tjänster. Den här förmånen omfattar automatiska uppdateringar, vilket eliminerar behovet av manuellt underhåll och säkerställer att PgBouncer håller sig uppdaterad med de senaste funktionerna och säkerhetskorrigeringarna.
• Stöd för offentlig och privat anslutning: Den inbyggda PgBouncer i din Azure Database for PostgreSQL flexibla servern ger stöd för både offentliga och privata anslutningar. Med det här stödet kan du upprätta säkra anslutningar via privata nätverk eller ansluta externt, beroende på dina specifika krav.
• Hög tillgänglighet (HA): Vid en failover, där en standbyserver får den primära rollen, startar PgBouncer om sömlöst på den nyss upphöjda standbyservern utan att några ändringar behöver göras i programmets anslutningssträng. Den här funktionen säkerställer kontinuerlig tillgänglighet och minimerar avbrott i programmet.
• Kostnadseffektiv: Det är kostnadseffektivt eftersom du inte behöver betala för extra beräkning som virtuell dator eller containrar, även om det har viss CPU-inverkan eftersom det är en annan process som körs på samma dator.

Genom att använda den inbyggda PgBouncer i en Azure Database for PostgreSQL flexibel server kan du njuta av bekvämligheten med förenklad konfiguration, tillförlitligheten för en hanterad tjänst, stöd för olika poollägen och sömlös hög tillgänglighet under redundansscenarier.

Limitations:

• Stöds inte för Burstable:PgBouncer stöds för närvarande inte för serverberäkningsnivån Burstable. Om du ändrar beräkningsnivån från Generell användning eller Minnesoptimerad till burstbar nivå förlorar du PgBouncer-funktionen.
• Återupprätta anslutningar efter omstarter: När servern startas om under skalningsåtgärder, ha-redundans eller en omstart startar PgBouncer om tillsammans med den virtuella serverdatorn. Befintliga anslutningar måste därför återupprättas.

I den här artikeln beskrivs olika sätt att implementera PgBouncer. I följande tabell sammanfattas vilken distributionsmetod du ska välja:

Urvalskriterier	PgBouncer på app-VM	PgBouncer på virtuell dator med ALB*	PgBouncer på AKS-sidovagn	PgBouncer som en tjänst	Inbyggd PgBouncer i Azure Database for PostgreSQL
Förenklad hantering
HA
Containerbaserade appar
Minskad nätverksbelastning och svarstid
Detaljerad kontroll över övervakning och felsökning

Förklaring

Svårighetsgrad	symbol
Easy
Medel
Svårt

*ALB: Azure Load Balancer.

Relaterat innehåll

• PgBouncer i Azure Database for PostgreSQL Flexible Server
• Anslutningsbibliotek