Utilizzare un pool di connessioni

Lakebase include un pool di connessioni PgBouncer predefinito che gestisce un pool di connessioni server e le condivide tra molte connessioni client. Il pooler supporta fino a 10.000 connessioni client simultanee, rendendolo una soluzione ideale per funzioni serverless, API Web e altre applicazioni che aprono molte connessioni di breve durata.

Il connection pooling richiede l'autenticazione nativa tramite password di Postgres. Non è disponibile per i ruoli OAuth.

Funzionamento del pool di connessioni

Ogni connessione Postgres utilizza risorse server perché Postgres crea un processo separato per ogni client. Man mano che le connessioni simultanee aumentano, possono esaurire rapidamente il limite di connessione del server.

Il pool di connessioni si trova tra l'applicazione e Postgres. I client si connettono al pooler e il pooler inoltra le query a un pool più piccolo di connessioni server effettive. Lakebase esegue PgBouncer in modalità transazione, quindi una connessione server viene mantenuta solo per la durata di una singola transazione e quindi restituita al pool. Ciò consente a molti client di condividere un piccolo pool di connessioni server.

Pool di connessioni

PgBouncer crea un pool separato per ogni combinazione di database e utente. Due utenti che si connettono allo stesso database ottengono pool indipendenti. Le dimensioni di ogni pool sono circa 90% del limite postgres max_connections , che varia in base alle dimensioni di calcolo.

Quando tutte le connessioni all'interno di un pool sono in uso, le nuove richieste dei client attendono in coda. Se una connessione server non diventa disponibile entro 2 minuti, il client riceve un errore di timeout.

Il diagramma mostra come più connessioni client di utenti diversi vengano instradate attraverso pool PgBouncer separati (uno per ogni combinazione utente/database), che condividono un numero limitato di connessioni Postgres reali.

Limiti di connessione

Tre limiti regolano il pool di connessioni:

Il limite di connessione diretta dipende dalle dimensioni di calcolo. Ad esempio, un'unità di calcolo 8 CU supporta 1.678 connessioni dirette e un'unità di calcolo 16 CU supporta 3.357. Per l'elenco completo, vedere Specifiche di calcolo.

Il limite di 10.000 connessioni client non significa 10.000 risultati di query simultanei. Rappresenta il numero massimo di connessioni client accettate da PgBouncer. Il numero di transazioni attive simultanee è vincolato dalle dimensioni del pool, ovvero circa 90% di max_connections.

Abilitare il pool di connessioni

Prerequisiti

• Il progetto di scalabilità automatica di Lakebase deve essere attivo.
• Nel progetto è necessario avere un ruolo con password nativa in Postgres. Per istruzioni, vedere Creare un ruolo password Postgres nativo.
• Per usare il pool di connessioni con istanze di calcolo di sola lettura, è necessario disporre di un endpoint a disponibilità elevata con Consenti l'accesso alle istanze di calcolo di sola lettura abilitate. Vedere Disponibilità elevata.

Gradi

1. Nell'app Lakebase passare al progetto e fare clic su Connetti.
2. Selezionare il ramo e il calcolo a cui connettersi.
3. Nel menu a discesa Ruolo, selezionare un ruolo nativo di password Postgres. L'opzione pooling delle connessioni è visibile solo se è selezionato un ruolo con password. È nascosto per i ruoli OAuth.
4. Attivare Pool di connessioni.
5. Copiare il stringa di connessione e usarlo nell'applicazione.

Formati di stringa di connessione

Le stringhe di connessione del pooler usano un nome host diverso rispetto alle connessioni di database dirette. Il nome host include -pooler dopo l'ID endpoint per il calcolo di lettura/scrittura o -ro-pooler per il calcolo di sola lettura:

Entrambe usano la porta 5432.

Configurazione di PgBouncer

Lakebase gestisce PgBouncer con le impostazioni seguenti. Queste impostazioni sono fisse e non possono essere personalizzate.

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

Modalità transazione

La modalità transazione migliora l'efficienza della connessione, ma limita alcune funzionalità di Postgres che richiedono una connessione server persistente. Le funzionalità seguenti non sono disponibili quando si usa il pool di connessioni:

• Istruzioni preparate a livello SQL: PREPARE e DEALLOCATE non sono supportate in modalità transazione. Le istruzioni preparate a livello di driver (usate internamente da psycopg, node-postgres, JDBC e librerie simili) funzionano correttamente tramite il supporto a livello di protocollo di PgBouncer. Per JDBC, se vengono visualizzati errori correlati alle istruzioni preparate, impostare prepareThreshold=0 per disabilitare la memorizzazione nella cache delle istruzioni preparate lato server nominate.

• Impostazioni a livello di sessione: SET i comandi non vengono mantenuti tra le transazioni perché ogni transazione può usare una connessione server diversa. Per esempio:

  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
  

  Per applicare un'impostazione in modo permanente, usare ALTER ROLE invece:

  ALTER ROLE myrole SET search_path TO myschema, public;
  

• Tabelle temporanee mantenute nella sessione: le tabelle temporanee che vengono mantenute tra le transazioni non sono disponibili. Una connessione restituita al pool può essere assegnata a un client diverso nella transazione successiva.

• WITH HOLD cursori: i cursori dichiarati con WITH HOLD richiedono una connessione permanente e non sono supportati.

• Blocchi consultivi: PgBouncer non supporta i blocchi consultivi. I blocchi consultivi richiedono una connessione server persistente, che non è disponibile in modalità di transazione.

• LISTEN/NOTIFY: non supportato. Usare una connessione diretta (non in pool) per le applicazioni che necessitano della messaggistica pub/sub.

• pg_dump e le migrazioni dello schema: Usare una connessione diretta per pg_dump, le migrazioni dello schema e altri strumenti che si basano sullo stato a livello di sessione.