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 klientanslutningar, 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-roller.

Så här fungerar anslutningspooler

Varje Postgres-anslutning förbrukar serverresurser eftersom Postgres skapar en separat process för varje klient. När samtidiga anslutningar växer kan de 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. Lakebase kör PgBouncer i transaktionsläge, så en serveranslutning hålls endast under en enda transaktion och returneras sedan till poolen. På så sätt kan många klienter dela en liten pool med serveranslutningar.

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 Postgres-gränsen max_connections , vilket varierar beroende på beräkningsstorlek.

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.

Diagrammet visar hur flera klientanslutningar från olika användare dirigeras via separata PgBouncer-pooler (en per kombination av användare/databas), som delar ett begränsat antal faktiska Postgres-anslutningar.

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.

Gränsen på 10 000 klientanslutningar innebär inte 10 000 samtidiga frågeresultat. Den representerar det maximala antalet klientanslutningar som PgBouncer accepterar. Antalet samtidiga aktiva transaktioner begränsas av poolstorleken, vilket är cirka 90% av max_connections.

Aktivera anslutningspooler

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 anslutningspooler med skrivskyddade beräkningsinstanser måste du ha en slutpunkt för hög tillgänglighet med Tillåt åtkomst till skrivskyddade beräkningsinstanser aktiverade. Se Hög tillgänglighet.

Instruktioner

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. Anslutningspoolsväxeln visas bara när en lösenordsroll har valts. Den är dold för OAuth-roller.
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. Värdnamnet innehåller -pooler efter slutpunkts-ID:t för beräkning med läs- och skrivåtkomst, eller -ro-pooler för skrivskyddad beräkning:

Båda använder port 5432.

PgBouncer-konfiguration

Lakebase hanterar PgBouncer med följande inställningar. De här inställningarna är fasta och kan inte anpassas.

[pgbouncer]
pool_mode=transaction
max_client_conn=10000
default_pool_size=0.9 * max_connections
max_prepared_statements=1000
query_wait_timeout=120

Transaktionsläge

Transaktionsläget förbättrar anslutningseffektiviteten men begränsar vissa Postgres-funktioner som kräver en beständig serveranslutning. Följande 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 psycopg, 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.