Il est possible qu'une partie ou l'ensemble des informations de cette page ne s'appliquent pas au Cloud de confiance S3NS. Pour en savoir plus, consultez Différences par rapport à Google Cloud.

Cette page a été traduite par l'API Cloud Translation.

Présentation du pool de connexions géré

MySQL | PostgreSQL | SQL Server

Cette page décrit ce qu'est le pooling de connexions géré et comment l'utiliser pour optimiser la gestion des connexions de base de données pour vos instances Cloud SQL à l'aide du pooling.

Le pooling de connexions géré vous permet de faire évoluer vos charges de travail en optimisant l'utilisation des ressources et la latence de connexion pour vos instances Cloud SQL à l'aide du pooling. Le regroupement de connexions géré attribue dynamiquement des connexions de serveur aux requêtes entrantes lorsque cela est possible. Cela permet d'améliorer considérablement les performances, en particulier pour les connexions à grande échelle, en absorbant les pics de connexion soudains et en réutilisant les connexions à la base de données existantes. Au lieu de se connecter à une base de données spécifique, le regroupement de connexions géré se connecte à un cluster de poolers, ce qui permet de réduire les temps de connexion et d'améliorer l'évolutivité de vos charges de travail.

Chaque pool est associé à une base de données et à un utilisateur uniques. Une fois le client authentifié, le pool tente de réutiliser l'une des connexions serveur inactives du pool pour connecter la base de données au serveur. Si aucune connexion de serveur n'est disponible, une nouvelle connexion de serveur est créée dans le pool pour connecter la base de données. Le nombre de poolers utilisés dépend du nombre de cœurs de processeur virtuel de votre instance.

Bien que vous puissiez utiliser le pool de connexions géré pour toutes les charges de travail transactionnelles, il offre le meilleur débit et la meilleure latence pour les applications qui contiennent des connexions de courte durée ou qui entraînent un pic de connexions.

Pour les connexions de longue durée, les performances de connexion à l'aide du pooling de connexions géré peuvent être légèrement inférieures à celles d'une connexion directe. Dans ce cas, le regroupement de connexions géré permet de mettre à l'échelle les connexions lorsque leur nombre est très élevé. Toutefois, pour les applications qui établissent généralement des connexions à longue durée de vie, vous pouvez éviter d'utiliser le regroupement de connexions.

Vous pouvez utiliser Identity and Access Management pour sécuriser les connexions, en fonction du port. Pour en savoir plus sur le fonctionnement d'IAM dans Cloud SQL et sur ses restrictions, consultez Authentification IAM.

Pour en savoir plus sur l'activation du pooling de connexions géré, consultez Configurer le pooling de connexions géré.

Conditions requises

Pour utiliser le pooling de connexions géré, votre instance doit répondre aux exigences suivantes :

Votre instance doit être une instance Cloud SQL Enterprise Plus.
Vous devez être connecté à votre instance en utilisant uniquement une connexion directe ou le proxy d'authentification Cloud SQL.
Votre instance doit être configurée pour l'accès aux services privés, utiliser une adresse IP publique ou être une nouvelle instance avec Private Service Connect activé.
Votre instance doit utiliser la nouvelle architecture réseau Cloud SQL.
Le regroupement de connexions géré nécessite une version de maintenance minimale de POSTGRES_$version.R20250727.00_14. Pour en savoir plus sur la maintenance en libre-service, consultez Effectuer la maintenance en libre-service.

Ports utilisés par le pool de connexions géré pour les instances Cloud SQL

Lorsque vous activez le pool de connexions géré, les ports utilisés par les instances Cloud SQL pour diffuser le trafic de base de données changent. Vous pouvez utiliser Identity and Access Management pour sécuriser les connexions, en fonction du port.

Les ports utilisés par le pooling de connexions géré et leurs options IAM disponibles sont les suivants :

Port TCP 5432 : utilisé pour les connexions directes par le serveur de base de données Postgres. Il s'agit du numéro de port par défaut pour se connecter directement à l'aide du client psql.
Port TCP 6432 : utilisé pour les connexions directes par le serveur Managed Connection Pooling. Pour vous connecter à l'aide de ce port, spécifiez psql -p 6432 lorsque vous vous connectez directement à l'aide du client psql.

Vous pouvez utiliser n'importe quelle option d'authentification IAM lorsque vous utilisez ce port.
Port TCP 3307 : utilisé pour les connexions au proxy d'authentification Cloud SQL uniquement par un serveur de pool de connexions géré. Lorsque vous utilisez le proxy d'authentification Cloud SQL pour vous connecter au pooling de connexions géré, ce numéro de port est configuré avec le client du proxy d'authentification Cloud SQL et ne peut pas être modifié.

Vous pouvez utiliser n'importe quelle option d'authentification IAM ou l'authentification IAM automatique pour les bases de données avec ce port.

Options de mise en commun

Le regroupement de connexions géré vous permet de gérer la façon dont les connexions sont regroupées à l'aide du paramètre pool_mode. Vous pouvez utiliser les options de mise en commun suivantes :

transaction (par défaut) : regroupe les connexions au niveau d'une transaction. Les connexions sont renvoyées au pool une fois chaque transaction terminée. Cloud SQL recommande d'utiliser le mode de regroupement transaction pour les connexions de courte durée.
session : regroupe les connexions au niveau de la session. Chaque session utilise une connexion serveur dédiée qui maintient un état de session. Cela réduit l'efficacité du pooling. Lorsqu'un client se déconnecte, le serveur revient au pool de connexions.

Options de configuration avancées

Vous pouvez personnaliser le regroupement de connexions géré à l'aide des options de configuration suivantes :

Nom de la configuration	Description
`max_pool_size`	Nombre maximal de connexions au serveur autorisées pour une paire base de données/utilisateur dans chaque pool de connexions. La valeur par défaut est de 50 connexions.
`min_pool_size`	Nombre minimal de connexions au serveur disponibles à tout moment dans chaque pool de connexions. Si le nombre de connexions au serveur est inférieur à `min_pool_size`, ce paramètre ajoute des connexions au serveur au pool. Cela permet de gérer les augmentations soudaines de la charge de la base de données après des périodes d'inactivité et de s'assurer que les connexions sont disponibles et prêtes à l'emploi. La valeur par défaut est de 0 connexion.
`max_client_connections`	Nombre maximal de connexions autorisées pour votre instance lorsque vous utilisez le pool de connexions géré. La valeur par défaut est de 5 000 connexions.
`max_prepared_statements`	Nombre maximal d'instructions préparées nommées au niveau du protocole prises en charge dans le mode de mise en pool `transaction`. Définir cette option sur 0 désactive la compatibilité avec les instructions préparées. Pour des performances optimales, cette valeur doit être supérieure au nombre de requêtes préparées couramment utilisées dans votre base de données. Un nombre élevé d'instructions préparées dans le pool de connexions géré peut entraîner une augmentation de l'utilisation de la mémoire. La valeur par défaut est de zéro instruction.
`client_connection_idle_timeout`	Durée pendant laquelle une connexion client reste inactive avant d'expirer. Cette valeur peut être comprise entre 0 et 2 147 483 secondes. La valeur par défaut est de 0 seconde.
`server_connection_idle_timeout`	Durée pendant laquelle une connexion au serveur reste inactive avant d'expirer. Cette valeur peut être comprise entre 0 et 2 147 483 secondes. La valeur par défaut est de 600 secondes.
`query_wait_timeout`	Durée pendant laquelle une requête attend une connexion au serveur dans un pool avant d'expirer. Si vous définissez cette option sur 0, elle est désactivée, ce qui permet la mise en file d'attente indéfinie du client. L'activation de cette option empêche les serveurs qui ne répondent pas de bloquer les connexions. Cette valeur peut être comprise entre 0 et 2 147 483 secondes. La valeur par défaut est de 120 secondes.
`ignore_startup_parameters`	Les paramètres que vous souhaitez ignorer et qui ne sont pas suivis par défaut dans les paquets de démarrage du pool de connexions géré.
`server_lifetime`	Durée maximale pendant laquelle une connexion au serveur est inutilisée avant que le regroupement de connexions géré ne la ferme. Si la valeur est définie sur 0 seconde, la connexion est immédiatement fermée après utilisation. La valeur par défaut est de 3 600 secondes.

Limites

Lorsque vous utilisez le pool de connexions géré avec vos instances Cloud SQL Enterprise Plus, tenez compte des limites suivantes :

L'activation du pooling de connexions géré sur une instance existante entraîne le redémarrage de la base de données.
Lorsque vous utilisez l'API Cloud SQL pour activer, désactiver ou configurer le pooling de connexions géré, l'API instance.update ne peut pas contenir d'autres mises à jour de la configuration de l'instance.
Le pooling de connexions géré ne peut être utilisé qu'avec le proxy d'authentification Cloud SQL version 2.15.2 et ultérieures.
Si vous utilisez le connecteur de langage Go Cloud SQL, nous vous recommandons d'utiliser au minimum la version 1.24 de Go. Si vous utilisez Go version 1.23 ou antérieure, vous pouvez rencontrer des limitations de performances lorsque vous utilisez le pool de connexions géré.
Si vous utilisez le pooling de connexions géré en mode pooling transaction, les fonctionnalités SQL suivantes ne sont pas prises en charge :
- SET/RESET
- LISTEN
- WITH HOLD CURSOR
- PREPARE/DEALLOCATE
- Tables temporaires PRESERVE/DELETE ROW
- LOAD
- Verrous consultatifs au niveau de la session
Si vous utilisez la bibliothèque d'interface de base de données asyncpg pour le pooler Managed Connection Pooling sur les ports 3307 et 6432, vous devez définir max_prepared_statements sur une valeur supérieure à 0 pour activer la prise en charge des instructions préparées dans le pooler Managed Connection Pooling.
Si vous utilisez la version 17 de Cloud SQL pour PostgreSQL, l'option sslnegotiation=direct n'est pas compatible.
Le suivi des adresses IP des clients n'est pas compatible avec le pooling de connexions géré. Si vous activez l'option Stocker les adresses IP des clients dans les insights sur les requêtes, les adresses IP des clients s'affichent sous la forme local au lieu de l'adresse IP elle-même.
Si votre instance utilise le proxy d'authentification Cloud SQL et que le regroupement de connexions géré est activé, l'authentification IAM manuelle pour les bases de données n'est pas compatible. Vous ne pouvez utiliser que l'authentification IAM automatique.

Connexions au serveur utilisées par le regroupement de connexions géré

La configuration de la base de données max_connections limite le nombre maximal de connexions au serveur qu'un pooler peut utiliser dans le pool de connexions géré. Cloud SQL recommande d'ajuster cette valeur en fonction des exigences de charge de travail de votre instance et de la taille de l'instance de base de données. En cas de charge maximale, le nombre de connexions pour l'authentification peut devenir très élevé.

Si vous utilisez la valeur par défaut max_pool_size de 50 pools sur votre instance, nous vous recommandons de réserver au moins 15 connexions de serveur par processeur pour le regroupement de connexions géré lorsque vous définissez l'indicateur max_connections pour votre base de données. Pour en savoir plus sur l'option max_connections, consultez Connexions simultanées maximales. Pour modifier l'option max_connections pour votre instance, consultez Configurer des options de base de données.