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 de 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. 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 regroupement de connexions géré pour toutes les charges de travail transactionnelles, il offre le meilleur débit et la meilleure latence avec 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 utiliser des connexions directes à votre instance.
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 à l'aide d'une connexion directe ou du proxy d'authentification Cloud SQL uniquement.
Vous devez être connecté à votre instance à l'aide d'un nom d'utilisateur et d'un mot de passe valides. Les utilisateurs IAM et les groupes IAM ne sont pas compatibles avec le regroupement de connexions géré.
Le regroupement de connexions géré nécessite une version de maintenance minimale de POSTGRES_$version.R20250302.00_04. Pour en savoir plus, consultez Effectuer une maintenance en libre-service.
Ports utilisés par le pool de connexions géré pour les instances Cloud SQL
Lorsque vous activez le pooling de connexions géré, les ports utilisés par les instances Cloud SQL pour diffuser le trafic de base de données changent. Les ports utilisés par le pool de connexions géré 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 utilisé lors d'une connexion directe à l'aide du client psql.
Port TCP 6432 : utilisé pour les connexions directes par le pooler 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.
Port TCP 3307 : utilisé pour les connexions au proxy d'authentification Cloud SQL uniquement par un pooler Managed Connection Pooling. Lorsque vous utilisez le proxy d'authentification Cloud SQL pour vous connecter au pooler Managed Connection Pooling, ce numéro de port est configuré avec le client du proxy d'authentification Cloud SQL et ne peut pas être modifié.
Options de configuration avancées
Le regroupement de connexions géré propose les options de regroupement suivantes que vous pouvez définir à l'aide du paramètre pool_mode :
transaction (par défaut) : regroupe les connexions au niveau d'une transaction.
session : regroupe les connexions au niveau de la session.
max_pool_size : taille maximale du pool de connexions. La valeur par défaut est de 50 connexions.
min_pool_size : taille seuil du pool de connexions. Si le nombre de connexions au serveur est inférieur à min_pool_size, ajoutez d'autres connexions au serveur au pool. La valeur par défaut est de 0 connexion.
max_client_connections : nombre maximal de connexions autorisées pour votre instance. La valeur par défaut est de 5 000 connexions.
client_connection_idle_timeout : durée d'inactivité d'une connexion client avant son expiration. 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 : délai d'attente d'une requête avant expiration.
Cette valeur peut être comprise entre 0 et 2 147 483 secondes. La valeur par défaut est de 120 secondes.
max_prepared_statements : nombre maximal de commandes d'instructions préparées nommées au niveau du protocole compatibles avec le mode de mise en pool des transactions. La valeur par défaut est de zéro instruction.
ignore_startup_parameters : paramètres que vous souhaitez ignorer et qui ne sont pas suivis par défaut dans les paquets de démarrage de Managed Connection Pooling.
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. La valeur par défaut est de 3 600 secondes.
Limites
Lorsque vous utilisez le pooling 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.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[],[],null,["# Managed Connection Pooling overview\n\n\u003cbr /\u003e\n\n[MySQL](/sql/docs/mysql/managed-connection-pooling \"View this page for the MySQL database engine\") \\| PostgreSQL \\| SQL Server\n\n\u003cbr /\u003e\n\n|\n| **Preview\n| --- [Managed Connection Pooling](/sql/docs/postgres/managed-connection-pooling)**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| You can process personal data for this feature as outlined in the\n| [Cloud Data Processing\n| Addendum](/terms/data-processing-addendum), subject to the obligations and restrictions described in the agreement under\n| which you access Google Cloud.\n|\n| Pre-GA features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nThis page describes what Managed Connection Pooling is and how to use it with your\nCloud SQL instances.\n\nManaged Connection Pooling lets you scale your workloads by optimizing resource utilization\nand connection latency for your Cloud SQL for PostgreSQL instances using pooling.\n\nManaged Connection Pooling dynamically assigns server connections to\nincoming requests when possible. This delivers significant performance\nimprovements, especially for scaled connections, by absorbing sudden\nconnection spikes and reusing existing database connections. Instead of\nconnecting to a particular database, Managed Connection Pooling connects to a\ncluster of poolers, which provide shorter connection times and scalability\nfor your workloads. The number of poolers used is based on the number of vCPU\ncores of your instance.\n\n\nWhile you can use Managed Connection Pooling for any transactional workloads,\nManaged Connection Pooling provides the most throughput and latency benefit with applications\nthat contain short-lived connections, or applications that result in a\nconnection surge.\n\nFor long-lived connections, the connection performance using\nManaged Connection Pooling can be slightly lower than when using a direct\nconnection. In this case, Managed Connection Pooling provides connection\nscaling when the number of connections is very high. However, for\napplications that typically establish long-lived connections, you might use\ndirect connections to your instance instead.\n\nFor more information on how to enable Managed Connection Pooling, see\n[Configure Managed Connection Pooling](/sql/docs/postgres/configure-mcp).\n\nRequirements\n------------\n\nTo use Managed Connection Pooling, your instance must meet the following requirements:\n\n- Your instance must be a Cloud SQL Enterprise Plus edition instance.\n- You must be connected to your instance using a direct connection, or the Cloud SQL Auth Proxy only.\n- You must be connected to your instance using a valid username and password. IAM and IAM group users aren't supported when using Managed Connection Pooling.\n- Your instance must either be set up for [private service access](/sql/docs/postgres/private-ip#set_up_private_services_access_for_your_network), use public IP, or be a new instance with [Private Service Connect](/sql/docs/postgres/about-private-service-connect) enabled.\n- Your instance must use the new [Cloud SQL network architecture](/sql/docs/postgres/upgrade-cloud-sql-instance-new-network-architecture).\n- Managed Connection Pooling requires a minimum maintenance version number of `POSTGRES_$version.R20250302.00_04`. For more information, see [Perform self-service maintenance](/sql/docs/postgres/self-service-maintenance).\n\nPorts used by Managed Connection Pooling for Cloud SQL instances\n----------------------------------------------------------------\n\nWhen you enable Managed Connection Pooling, the ports used by Cloud SQL instances to serve database traffic change. The ports used by Managed Connection Pooling are as follows:\n\n- **TCP port 5432** : used for direct connections by the Postgres database server. This is the default port number used when [directly connecting using psql client](/sql/docs/postgres/connect-admin-ip#connect).\n- **TCP port 6432** : used for direct connections by the Managed Connection Pooling pooler. To connect using this port, specify `psql -p 6432` when [directly connecting using psql client](/sql/docs/postgres/connect-admin-ip#connect).\n- **TCP port 3307**: used for the Cloud SQL Auth Proxy only connections by a Managed Connection Pooling pooler. When you use Cloud SQL Auth Proxy to connect to Managed Connection Pooling pooler, this port number is configured with the Cloud SQL Auth Proxy client and can't be changed.\n\nAvailable configuration options\n-------------------------------\n\nManaged Connection Pooling offers the following pooling options that you can set using the `pool_mode` parameter:\n\n\u003cbr /\u003e\n\n- `transaction` (default): pools connections at a transaction level.\n- `session`: pools connections at a session level.\n\n| **Note:** The maximum number of server connections used by the pooler in Managed Connection Pooling is limited by the `max_connections` database configuration. Cloud SQL recommends adjusting this value based on your instance's workload requirements and the database instance size. For more information about the `max_connections` flag, see [Maximum concurrent connections](/sql/docs/quotas#maximum_concurrent_connections). To modify the `max_connections` database configuration flag for your instance, see [Configure database flags](/sql/docs/postgres/flags#config).\n\nYou can also\n[customize Managed Connection Pooling](/sql/docs/postgres/configure-mcp#modify-mcp)\nby using the following configuration parameters:\n\n- `max_pool_size`: the maximum size of the connection pool. The default value is 50 connections.\n- `min_pool_size`: the threshold size of the connection pool. If the number of server connections is less than `min_pool_size`, then add more server connections to the pool. The default value is 0 connections.\n- `max_client_connections`: the maximum number of connections allowed for your instance. The default value is 5,000 connections.\n- `client_connection_idle_timeout`: the time that a client-connection remains idle before it times out. This value can range from 0 to 2,147,483 seconds, and the default value is 0 seconds.\n- `server_connection_idle_timeout`: the time that a server connection remains idle before it times out. This value can range from 0 to 2,147,483 seconds, and the default value is 600 seconds.\n- `query_wait_timeout`: the time that a query waits until it times out. This value can range from 0 to 2,147,483 seconds, and the default value is 120 seconds.\n- `max_prepared_statements`: the maximum number of protocol-level named prepared statements commands supported in transaction pooling mode. The default value is 0 statements.\n- `ignore_startup_parameters`: the parameters you want ignored, that aren't tracked in Managed Connection Pooling's startup packets by default.\n- `server_lifetime`: the maximum time a server connection is unused before Managed Connection Pooling closes it. The default value is 3600 seconds.\n\nLimitations\n-----------\n\nConsider the following limitations when using Managed Connection Pooling with\nyour Cloud SQL Enterprise Plus edition instances:\n\n- Enabling Managed Connection Pooling on an existing instance results in a database restart.\n- When you use the Cloud SQL API to enable, disable, or configure Managed Connection Pooling, the `instance.update` API can't contain any other instance configuration updates.\n- Managed Connection Pooling can only be used with Cloud SQL Auth Proxy version 2.15.2 and later.\n- If you're using the Cloud SQL Go Language Connector, then we recommend a minimum Go version of `1.24`. If you use Go version 1.23 or earlier, then you might experience limitations on performance when using Managed Connection Pooling.\n- If you're using Managed Connection Pooling in `transaction` pooling mode, then\n the following SQL features aren't supported:\n\n - `SET/RESET`\n - `LISTEN`\n - `WITH HOLD CURSOR`\n - `PREPARE/DEALLOCATE`\n - `PRESERVE/DELETE ROW` temp tables\n - `LOAD`\n - Session-level advisory locks\n- If you're using the\n [asyncpg database interface library](https://magicstack.github.io/asyncpg/current/)\n for Managed Connection Pooling pooler on port 3307 and 6432, then you must update the\n `max_prepared_statements` to a value larger than 0 to enable support for\n prepared statements in Managed Connection Pooling pooler.\n\n- If you're using Cloud SQL for PostgreSQL version 17, then the\n `sslnegotiation=direct` option isn't supported.\n\n- Client IP tracking isn't supported with Managed Connection Pooling. If you enable\n *store client IP addresses* in [query insights](/sql/docs/postgres/using-query-insights),\n then client IP addresses are displayed as `local` instead of the IP address\n itself.\n\nWhat's next\n-----------\n\n- [Create an instance](/sql/docs/postgres/create-instance)\n- [Configure Managed Connection Pooling](/sql/docs/postgres/configure-mcp)"]]
