Utiliser le pool de connexions

Lakebase inclut un Pool de connexions PgBouncer intégré qui maintient un Pool de connexions de serveur et les partage entre plusieurs connexions client. Le pooler prend en charge jusqu'à 10 000 connexions client simultanées, ce qui le rend idéal pour les fonctions Serverless, les APIs web et d'autres applications qui ouvrent de nombreuses connexions de courte durée.

Le regroupement de connexions nécessite une authentification native par mot de passe Postgres. Il n'est pas disponible pour les rôles OAuth.

Fonctionnement du pool de connexions

Chaque connexion Postgres consomme des ressources serveur car Postgres crée un processus distinct pour chaque client. À mesure que les connexions concurrentes augmentent, elles peuvent rapidement épuiser la limite de connexion du serveur.

Le pooler de connexion se situe entre votre application et Postgres. Les clients se connectent au pooler, et le pooler transfère les query vers un pool plus petit de connexions serveur réelles. Lakebase exécute PgBouncer en mode transaction, de sorte qu'une connexion serveur est maintenue uniquement pendant la durée d'une seule transaction, puis renvoyée au pool. Cela permet à de nombreux clients de partager un petit pool de connexions serveur.

Pools de connexions

PgBouncer crée un pool séparé pour chaque combinaison de base de données et d'utilisateur. Deux utilisateurs se connectant à la même base de données obtiennent des Pools indépendants. La taille de chaque pool correspond à environ 90 % de la limite Postgres max_connections, qui varie en fonction de la taille de compute.

Lorsque toutes les connexions d'un Pool sont utilisées, les nouvelles requêtes client attendent dans une file d'attente. Si une connexion serveur n'est pas disponible dans les 2 minutes, le client reçoit une erreur de délai d'attente.

Le diagramme montre comment plusieurs connexions client de différents utilisateurs sont acheminées via des Pools PgBouncer séparés (un par combinaison utilisateur/base de données), qui partagent un nombre limité de connexions Postgres réelles.

Limites de connexion

Trois limites régissent la mise en commun des connexions :

Limite	Valeur	Ce qu'il contrôle
Connexions client (max_client_conn)	10 000	Nombre maximal de connexions de votre application à PgBouncer
Taille du Pool (default_pool_size)	~90 % de max_connections	Connexions de serveur actives par paire (utilisateur, base de données)
Connexions directes (max_connections)	Varie selon la taille de compute.	Nombre maximal de connexions directes Postgres

Limite	Valeur	Ce qu'il contrôle
Connexions client (max_client_conn)	10 000	Nombre maximal de connexions de votre application à PgBouncer
Taille du Pool (default_pool_size)	~90 % de max_connections	Connexions de serveur actives par paire (utilisateur, base de données)
Connexions directes (max_connections)	Varie selon la taille de compute.	Nombre maximal de connexions directes Postgres

La limite de connexion directe dépend de la taille de votre compute. Par exemple, un compute de 8 CU prend en charge 1 678 connexions directes et un compute de 16 CU en prend en charge 3 357. Pour la liste complète, consultez les spécifications du compute.

La limite de connexion client de 10 000 ne signifie pas 10 000 résultats de query simultanés. Il représente le nombre maximum de connexions client acceptées par PgBouncer. Le nombre de transactions actives simultanées est délimité par la taille du pool, qui correspond à environ 90 % de max_connections.

Activer la mise en pool des connexions

Prérequis

• Votre projet Lakebase Autoscaling doit être actif.
• Vous devez disposer d'un rôle de mot de passe Postgres natif dans le projet. Pour obtenir des instructions, consultez Créer un rôle de mot de passe Postgres natif.
• Pour utiliser la mise en commun des connexions avec des instances de compute en lecture seule, vous devez disposer d'un Endpoint à haute disponibilité avec l'option **Autoriser l'accès aux instances de compute en lecture seule** activée. Consultez Haute disponibilité.

Étapes

1. Dans l'application Lakebase, accédez à votre projet et cliquez sur **Connecter**.
2. Sélectionnez la branch et le compute auxquels vous souhaitez vous connecter.
3. Dans le menu déroulant Rôle , sélectionnez un rôle de mot de passe Postgres natif. Le commutateur Pool de connexions n'est visible que lorsqu'un rôle de mot de passe est sélectionné. Il est masqué pour les rôles OAuth.
4. Activer le Pooling de connexions.
5. Copiez la chaîne de connexion et utilisez-la dans votre application.

Formats de chaînes de connexion

Les chaînes de connexion du pooler utilisent un Hostname différent des connexions de base de données directes. Le hostname inclut -pooler après l'ID d'Endpoint pour le compute en lecture-écriture, ou -ro-pooler pour le compute en lecture seule :

Type de compute	Format du Hostname	Quand utiliser
compute en lecture-écriture	<endpoint-id>-pooler.<region>.<cloud>.databricks.com	Tout le trafic de lecture et d'écriture
Compute en lecture seule	<endpoint-id>-ro-pooler.<region>.<cloud>.databricks.com	Trafic en lecture uniquement. Nécessite un Endpoint à haute disponibilité avec accès en lecture activé.

Type de compute	Format du Hostname	Quand utiliser
compute en lecture-écriture	<endpoint-id>-pooler.<region>.<cloud>.databricks.com	Tout le trafic de lecture et d'écriture
Compute en lecture seule	<endpoint-id>-ro-pooler.<region>.<cloud>.databricks.com	Trafic en lecture uniquement. Nécessite un Endpoint à haute disponibilité avec accès en lecture activé.

Les deux utilisent le port 5432.

remarque

Copiez votre chaîne de connexion du pooler directement depuis la boîte de dialogue Connecter dans l'application Lakebase pour obtenir le Hostname correct pour votre Endpoint, votre région et votre cloud.

Configuration de PgBouncer

Lakebase gère PgBouncer avec les paramètres suivants. Ces paramètres sont fixes et ne peuvent pas être personnalisés.

ini

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

Paramètre	Description
pool_mode=transaction	Les connexions serveur retournent au Pool après chaque transaction. Voir le mode de transaction.
max_client_conn=10000	Nombre maximal de connexions client simultanées acceptées par PgBouncer.
default_pool_size=0.9 * max_connections	Connexions de serveur actives par paire (utilisateur, base de données). Varie selon la taille de compute.
max_prepared_statements=1000	Autorise les instructions préparées au niveau du protocole en mode de transaction. Limite les instructions suivies à 1 000 par connexion client.
query_wait_timeout=120	Secondes qu'un client attend une connexion au serveur avant de recevoir une erreur de délai d'attente.

Paramètre	Description
pool_mode=transaction	Les connexions serveur retournent au Pool après chaque transaction. Voir le mode de transaction.
max_client_conn=10000	Nombre maximal de connexions client simultanées acceptées par PgBouncer.
default_pool_size=0.9 * max_connections	Connexions de serveur actives par paire (utilisateur, base de données). Varie selon la taille de compute.
max_prepared_statements=1000	Autorise les instructions préparées au niveau du protocole en mode de transaction. Limite les instructions suivies à 1 000 par connexion client.
query_wait_timeout=120	Secondes qu'un client attend une connexion au serveur avant de recevoir une erreur de délai d'attente.

Mode de transaction

Le mode de transaction améliore l'efficacité de la connexion mais restreint certaines fonctionnalités Postgres qui nécessitent une connexion au serveur persistante. Les fonctionnalités suivantes ne sont pas disponibles lorsque vous utilisez le gestionnaire de pool de connexions :

• Requêtes préparées au niveau SQL : les instructions PREPARE et DEALLOCATE ne sont pas prises en charge en mode transaction. Les requêtes préparées au niveau du Driver (utilisées en interne par psycopg, node-postgres, JDBC et des bibliothèques similaires) fonctionnent correctement grâce au support au niveau du protocole de PgBouncer. Pour JDBC, si vous rencontrez des erreurs liées aux requêtes préparées, définissez prepareThreshold=0 pour désactiver la mise en cache des requêtes préparées côté serveur nommées.

• Paramètres au niveau de la session : les commandes SET ne persistent pas au-delà des transactions, car chaque transaction peut utiliser une connexion serveur différente. Par exemple :

  SQL

  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

  Pour appliquer un paramètre de façon permanente, utilisez ALTER ROLE à la place :

  SQL

  ALTER ROLE myrole SET search_path TO myschema, public;

• **Tables temporaires de session** : les tables temporaires qui persistent entre les transactions ne sont pas disponibles. Une connexion renvoyée au Pool peut être attribuée à un client différent lors de la prochaine transaction.

• WITH HOLD curseurs : Les curseurs déclarés avec WITH HOLD nécessitent une connexion persistante et ne sont pas pris en charge.

• Verrous consultatifs : PgBouncer ne prend pas en charge les verrous consultatifs. Les verrous consultatifs nécessitent une connexion serveur persistante, qui n'est pas disponible en mode transactionnel.

• LISTEN** / **NOTIFY : Non pris en charge. Utilisez une connexion directe (non-Pool) pour les applications qui nécessitent une messagerie pub/sub.

• pg_dump ** et migrations de schémas** : Utilisez une connexion directe pour,pg_dump les migrations de schémas et d'autres outils qui dépendent de l'état de la session.

remarque

Pour les applications qui nécessitent des fonctionnalités Postgres au niveau de la session, utilisez une chaîne de connexion directe à partir de la boîte de dialogue Connexion sans activer l'interrupteur Regroupement de connexions .