Använd anslutningspoolning

Lakebase innehåller en inbyggd PgBouncer-anslutningspool som underhåller en pool med serveranslutningar och delar dem över många klientanslutningar. Pooler stöder upp till 10 000 samtidiga anslutningar, vilket gör det lämpligt för serverlösa funktioner, webb-API:er och andra program som öppnar många kortvariga anslutningar.

Anslutningspooler kräver intern Postgres-lösenordsautentisering. Den är inte tillgänglig för OAuth- eller Azure Databricks identitetsroller.

Så här fungerar anslutningspooler

Varje Postgres-anslutning förbrukar serverresurser eftersom Postgres skapar en separat process för varje klient. Program som öppnar många kortvariga anslutningar, till exempel webb-API:er och serverlösa funktioner, kan snabbt uttömma serverns anslutningsgräns.

Anslutningspoolen finns mellan ditt program och Postgres. Klienter ansluter till poolverktyget och poolverktyget vidarebefordrar frågor till en mindre pool med faktiska serveranslutningar. När en transaktion är klar returnerar poolhanteraren serveranslutningen till poolen, vilket gör den tillgänglig för nästa klient.

Lakebase kör PgBouncer i transaktionsläge. I transaktionsläge hålls en serveranslutning under en enskild transaktions varaktighet och returneras sedan till poolen. På så sätt kan många klienter dela en liten pool med serveranslutningar.

Transaktionsläget förbättrar anslutningseffektiviteten men begränsar vissa Postgres-funktioner som kräver en beständig serveranslutning. Se Begränsningar för transaktionsläge.

Anslutningspooler

PgBouncer skapar en separat pool för varje databas och användarkombination. Två användare som ansluter till samma databas får oberoende pooler. Storleken på varje pool är cirka 90% av beräkningsgränsen för direktanslutning.

När alla anslutningar i en pool används väntar nya klientbegäranden i en kö. Om en serveranslutning inte blir tillgänglig inom 2 minuter får klienten ett timeout-fel.

Anslutningsgränser

Tre gränser styr anslutningspooler:

Gränsen för direktanslutning beror på beräkningsstorleken. En 8 CU-beräkning stöder till exempel 1 678 direkta anslutningar och en 16 CU-beräkning stöder 3 357. Den fullständiga listan finns i Beräkningsspecifikationer.

Med anslutningspooler kan ditt program stödja mycket fler samtidiga användare än vad enbart direktanslutningsgränsen skulle tillåta.

Förutsättningar

• Ditt Lakebase Autoscaling-projekt måste vara aktivt.
• Du måste ha en intern Postgres-lösenordsroll i projektet. Anvisningar finns i Skapa en intern Postgres-lösenordsroll.
• Om du vill använda den skrivskyddade poolen måste du ha en slutpunkt med hög tillgänglighet med alternativet Tillåt åtkomst till skrivskyddade beräkningsinstanser aktiverat. Se Hög tillgänglighet.

Aktivera anslutningspooler

1. I Lakebase-appen går du till projektet och klickar på Anslut.
2. Välj den gren och beräkning som du vill ansluta till.
3. I listrutan Roll väljer du en intern Postgres-lösenordsroll. Växlingsknappen för anslutningspoolning visas bara när en lösenordsroll har valts. Den är dold för OAuth- och Azure Databricks identitetsroller.
4. Aktivera anslutningspooler.
5. Kopiera reťazec pripojenia och använd den i ditt program.

Format för anslutningssträngar

Anslutningssträngar för pooler använder ett annat värdnamn än direkta databasanslutningar:

Båda pooltyperna använder port 5432.

Begränsningar i transaktionsläge

Följande Postgres-funktioner är inte tillgängliga när du använder anslutningspoolen:

• Förberedda instruktioner på SQL-nivå: PREPARE och DEALLOCATE -instruktioner stöds inte i transaktionsläge. Förberedda instruktioner på drivrutinsnivå (används internt av psycopg2, node-postgres, JDBC och liknande bibliotek) fungerar korrekt via PgBouncer-stöd på protokollnivå. För JDBC, om du ser fel som rör förberedda instruktioner, anger du prepareThreshold=0 för att inaktivera namngiven cachelagring av förberedda instruktioner på serversidan.

• Inställningar på sessionsnivå: SET Kommandon bevaras inte mellan transaktioner eftersom varje transaktion kan använda en annan serveranslutning. Som exempel:

  BEGIN;
  SET search_path TO myschema;
  SELECT * FROM mytable; -- works in this transaction
  COMMIT;
  -- connection returns to pool after COMMIT
  SELECT * FROM mytable; -- ERROR: relation "mytable" does not exist
  

  Om du vill tillämpa en inställning permanent använder du ALTER ROLE i stället:

  ALTER ROLE myrole SET search_path TO myschema, public;
  

• Sessionsbaserade temporära tabeller: Temporära tabeller som bevaras mellan transaktioner är inte tillgängliga. En anslutning som returneras till poolen kan tilldelas till en annan klient i nästa transaktion.

• WITH HOLD markörer: Markörer som deklareras med WITH HOLD kräver en beständig anslutning och stöds inte.

• Rådgivande lås: PgBouncer stöder inte rådgivningslås. Rådgivande lås kräver en beständig serveranslutning som inte är tillgänglig i transaktionsläge.

• LISTEN/NOTIFY: Stöds inte. Använd en direktanslutning (icke-poolad) för program som kräver pub-/undermeddelanden.

• pg_dump och schemamigreringar: Använd en direktanslutning för pg_dump, schemamigreringar och andra verktyg som förlitar sig på sessionsnivåtillstånd.

Nästa steg

• Anslutningssträngar: Referens för anslutningssträngformat för direktanslutningar. Se Anslutningssträngar.
• Skapa Postgres-roller: Så här skapar du inbyggda Postgres-lösenordsroller som krävs för anslutningspooler. Se avsnittet Skapa Postgres-roller.
• Om autentisering: Jämförelse av OAuth- och lösenordsautentiseringsmetoder. Se Om autentisering.