Utiliser le regroupement de connexions

Lakebase inclut un pool de connexions PgBouncer intégré qui gère un pool de connexions serveur et les partage sur de nombreuses connexions clientes. Le pooleur prend en charge jusqu’à 10 000 connexions clientes simultanées, ce qui en fait un bon ajustement pour les fonctions serverless, les API web et d’autres applications qui ouvrent de nombreuses connexions de courte durée.

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

Fonctionnement du regroupement de connexions

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

Le pool de connexions se trouve entre votre application et Postgres. Les clients se connectent au pooler et le pooleur transfère les requêtes vers un plus petit pool de connexions serveur réelles. Lakebase exécute PgBouncer en mode transaction, donc une connexion de serveur est conservée uniquement pendant la durée d’une seule transaction, puis retournée au pool. Cela permet à de nombreux clients de partager un petit pool de connexions serveur.

Pools de connexions

PgBouncer crée un pool distinct pour chaque base de données et combinaison d’utilisateurs. Deux utilisateurs se connectant à la même base de données obtiennent des pools indépendants. La taille de chaque pool est d’environ 90% de la limite Postgres max_connections , qui varie en fonction de la taille de calcul.

Lorsque toutes les connexions d’un pool sont en cours d’utilisation, les nouvelles demandes clientes attendent dans une file d’attente. Si une connexion serveur ne devient pas disponible dans les 2 minutes, le client reçoit une erreur de délai d’expiration.

Le diagramme montre comment plusieurs connexions clientes provenant de différents utilisateurs routent via des pools PgBouncer distincts (une par combinaison utilisateur/base de données), qui partagent un nombre limité de connexions Postgres réelles.

Limites de connexion

Trois limites régissent le regroupement de connexions :

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

La limite de connexion cliente de 10 000 ne signifie pas 10 000 résultats de requête simultanés. Il représente le nombre maximal de connexions clientes que PgBouncer accepte. Le nombre de transactions actives simultanées est limité par la taille du pool, qui est d’environ 90% de max_connections.

Activer le regroupement de connexions

Prerequisites

• Votre projet de mise à l’échelle automatique Lakebase doit être actif.
• Vous devez avoir 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 le regroupement de connexions avec des instances de calcul en lecture seule, vous devez disposer d’un point de terminaison de haute disponibilité avec Autoriser l’accès aux instances de calcul en lecture seule activées. Consultez La haute disponibilité.

Steps

1. Dans l’application Lakebase, accédez à votre projet, puis cliquez sur Se connecter.
2. Sélectionnez la branche et le calcul auquel vous souhaitez vous connecter.
3. Dans la liste déroulante Rôle , sélectionnez un rôle de mot de passe Postgres natif. Le commutateur de regroupement de connexions est visible uniquement lorsqu’un rôle de mot de passe est sélectionné. Il est masqué pour les rôles OAuth.
4. Activez le regroupement de connexions.
5. Copiez le chaîne de connexion et utilisez-le dans votre application.

Formats de chaîne de connexion

Les chaînes de connexion du pool utilisent un nom d’hôte différent de celui des connexions de base de données directes. Le nom d’hôte inclut -pooler après l’ID de point de terminaison pour le calcul en lecture-écriture ou -ro-pooler pour le calcul en lecture seule :

Les deux utilisent le port 5432.

Configuration de PgBouncer

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

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

Mode transactionnel

Le mode transactionnel améliore l’efficacité de la connexion, mais limite certaines fonctionnalités Postgres qui nécessitent une connexion de serveur persistant. Les fonctionnalités suivantes ne sont pas disponibles lors de l’utilisation du pool de connexions :

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

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

  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 définitivement un paramètre, utilisez ALTER ROLE plutôt :

  ALTER ROLE myrole SET search_path TO myschema, public;
  

• Tables temporaires conservées par session : les tables temporaires qui persistent entre les transactions ne sont pas disponibles. Une connexion retournée au pool peut être affectée à un autre client dans la transaction suivante.

• 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 de serveur persistant, qui n’est pas disponible en mode transactionnel.

• LISTEN/NOTIFY: non pris en charge. Utilisez une connexion directe (non mise en pool) pour les applications qui nécessitent une messagerie pub/sous-messagerie.

• pg_dump et migrations de schéma: utilisez une connexion directe pour pg_dump, les migrations de schéma et d’autres outils qui dépendent de l’état de la session.