PgBouncer dans Azure Database pour PostgreSQL - Serveur flexible

Article
08/15/2024

S’APPLIQUE À : Azure Database pour PostgreSQL : serveur flexible

Azure Database pour PostgreSQL – Serveur flexible offre PgBouncer comme solution de regroupement de connexions intégrée. PgBouncer est une fonctionnalité facultative que vous pouvez activer pour chaque serveur de base de données individuellement. Elle est prise en charge sur les niveaux de calcul Usage général et À mémoire optimisée dans les réseaux d’accès public et privé.

PgBouncer s’exécute sur la même machine virtuelle que le serveur de base de données pour le serveur flexible Azure Database pour PostgreSQL. Postgres utilise un modèle basé sur les processus pour les connexions, de sorte que la maintenance de nombreuses connexions inactives est coûteuse. Postgres s’exécute dans des contraintes de ressources lorsque le serveur exécute plus de mille connexions. Le principal avantage de PgBouncer est qu’il améliore les connexions inactives et les connexions à courte durée de vie sur le serveur de base de données.

PgBouncer utilise un modèle léger qui exploite des entrée/sorties asynchrones. Il utilise les connexions Postgres uniquement si nécessaire, c'est-à-dire lorsqu'une transaction est ouverte ou lorsqu'une requête est active. Ce modèle permet une mise à l’échelle jusqu’à 10 000 connexions avec une faible surcharge.

PgBouncer s’exécute sur le port 6432 de votre serveur de base de données. Vous pouvez modifier la configuration de la connexion de base de données de votre application pour qu’elle utilise le même nom d’hôte, mais modifiez le port sur 6432 pour commencer à utiliser PgBouncer et tirer parti de la mise à l’échelle améliorée des connexions inactives.

PgBouncer dans le serveur flexible Azure Database pour PostgreSQL prend en charge l’authentification Microsoft Entra (Azure AD).

Activation et configuration de PgBouncer

Pour activer PgBouncer, accédez au volet Paramètres du serveur dans le portail Azure, recherchez PgBouncer et remplacez le paramètre pgbouncer.enabled par true. Il est inutile de redémarrer le serveur.

Vous pouvez configurer les paramètres PgBouncer à l’aide de ces paramètres.

Remarque

La liste suivante des paramètres de serveur PgBouncer est visible dans le volet Paramètres du serveur uniquement si le paramètre du serveur pgbouncer.enabled est défini sur true. Sinon, ils sont délibérément cachés.

Nom du paramètre	Description	Default
pgbouncer.default_pool_size	Définissez la valeur de ce paramètre sur le nombre de connexions par paire utilisateur/base de données.	50
pgbouncer.ignore_startup_parameters	Entrez une liste de paramètres séparés par des virgules que PgBouncer peut ignorer. Par exemple, vous pouvez laisser PgBouncer ignorer le paramètre `extra_float_digits`. Certains paramètres sont autorisés, tous les autres occasionnent une erreur. Cela est nécessaire pour tolérer les connexions Java Database Connectivity (JDBC) excessivement enthousiastes voulant définir de manière inconditionnelle `extra_float_digits=2` dans les paquets de démarrage. Utilisez cette option si la bibliothèque que vous utilisez signale des erreurs telles que `pq: unsupported startup parameter: extra_float_digits`.
pgbouncer.max_client_conn	Définissez la valeur de ce paramètre sur le plus grand nombre de connexions clientes à PgBouncer que vous souhaitez prendre en charge.	5 000
pgbouncer.max_prepared_statements	Lorsqu’il est défini sur une valeur non nulle PgBouncer, le protocole effectue le suivi des commandes préparées nommées au niveau du protocole envoyées par le client en mode de regroupement des transactions et des instructions.	0
pgbouncer.min_pool_size	Ajoutez plus de connexions au serveur pour le pool si le nombre actuel est inférieur à celui défini.	0
pgbouncer.pool_mode	Définissez cette valeur de paramètre sur TRANSACTION pour le regroupement de transactions (ce qui est le paramètre recommandé pour la plupart des charges de travail).	transaction
pgbouncer.query_wait_timeout	Durée maximale (en secondes) que les requêtes sont autorisées à passer en attente d’exécution. Si la requête n’est pas affectée à un serveur pendant ce temps, le client est déconnecté.	120
pgbouncer.server_idle_timeout	Une connexion de serveur ayant été inactive au-delà de ce nombre de secondes sera interrompue. Si la valeur est 0, le délai d’attente est désactivé.	600
pgbouncer.stats_users	Liste séparée par des virgules des utilisateurs de base de données autorisés à se connecter et à exécuter des requêtes en lecture seule sur la console pgBouncer.

Pour plus d’informations sur les configurations PgBouncer, consultez la documentation pgbouncer.ini.

Version de PgBouncer

Actuellement, la version de PgBouncer déployée sur toutes les versions principales prises en charge du moteur (16, 15, 14, 13, 12, 11), dans le serveur flexible Azure Database pour PostgreSQL, est la version 1.22.1.

Avantages

En utilisant la fonctionnalité PgBouncer intégrée avec un serveur flexible Azure Database pour PostgreSQL, vous pouvez bénéficier de ces avantages :

Commodité de la configuration simplifiée : étant donné que PgBouncer est intégré au serveur flexible Azure Database pour PostgreSQL, il n’est pas nécessaire d’effectuer une installation distincte ou une configuration complexe. Vous pouvez le configurer directement à partir des paramètres du serveur.
Fiabilité d’un service géré : PgBouncer offre les avantages des services gérés Azure. Par exemple, Azure gère les mises à jour de PgBouncer. Les mises à jour automatiques éliminent le besoin de maintenance manuelle et la garantissent que PgBouncer reste à jour avec les dernières fonctionnalités et les derniers correctifs de sécurité.
Prise en charge des différents types de connexions : PgBouncer dans le serveur flexible Azure Database pour PostgreSQL prend en charge les connexions publiques et privées. Vous pouvez l’utiliser pour établir des connexions sécurisées sur des réseaux privés ou de vous connecter en externe, en fonction de vos besoins précis.
Haute disponibilité dans les scénarios de basculement : si un serveur de secours est promu au rôle principal pendant un basculement, PgBouncer redémarre en toute transparence sur le serveur de secours nouvellement promu. Vous n’avez pas besoin de modifier la chaîne de connexion de l'application. Cette capacité permet de garantir une disponibilité continue et réduit les interruptions dans le pool de connexions de l’application.

Surveillance de PgBouncer

Métriques

Le serveur flexible Azure Database pour PostgreSQL fournit six métriques pour monitorer le regroupement de connexions PgBouncer :

Nom d’affichage	ID de la métrique	Unité	description	Dimension	Par défaut permis
Connexions clients actives (préversion)	`client_connections_active`	Count	Connexions à partir des clients associés à une connexion Azure Database pour PostgreSQL – Serveur flexible	`DatabaseName`	Non
Connexions clients en attente (préversion)	`client_connections_waiting`	Count	Connexions à partir de clients qui attendent qu’une connexion Azure Database pour PostgreSQL – Serveur flexible soit à leur disposition	`DatabaseName`	Non
Connexions actives sur le serveur (préversion)	`server_connections_active`	Count	Connexions au serveur flexible Azure Database pour PostgreSQL qu’une connexion client utilise	`DatabaseName`	Non
Connexions inactives sur le serveur (préversion)	`server_connections_idle`	Count	Connexions au serveur flexible Azure Database pour PostgreSQL inactives et prêtes à servir une nouvelle connexion client	`DatabaseName`	Non
Nombre total de connexions groupées (préversion)	`total_pooled_connections`	Count	Nombre actuel de connexions mises en pool	`DatabaseName`	Non
Nombre de pools de connexions (préversion)	`num_pools`	Count	Nombre total de pools de connexions	`DatabaseName`	Non

Pour découvrir plus d’informations, reportez-vous aux métriques de PgBouncer.

Console d’administration

PgBouncer fournit également une base de données interne appelée pgbouncer. Lorsque vous vous connectez à cette base de données, vous pouvez exécuter des commandes SHOW qui fournissent des informations sur l’état actuel de PgBouncer.

Pour se connecter à la base de données pgbouncer :

Définissez le paramètre pgBouncer.stats_users sur le nom d’un utilisateur existant (par exemple, myUser) et appliquez les modifications.

Connectez-vous à la base de données pgbouncer en tant qu’utilisateur et définissez le port comme 6432 :

psql "host=myPgServer.postgres.database.azure.com port=6432 dbname=pgbouncer user=myUser password=myPassword sslmode=require"

Une fois que vous êtes connecté à la base de données, utilisez les commandes SHOW pour afficher les statistiques PgBouncer :

SHOW HELP : répertorie toutes les commandes SHOW disponibles.
SHOW POOLS : affiche le nombre de connexions dans chaque état pour chaque pool.
SHOW DATABASES : affiche les limites de connexion appliquées actuellement pour chaque base de données.
SHOW STATS : affiche les statistiques sur les requêtes et le trafic pour chaque base de données.

Pour plus d’informations sur les commandes SHOW PgBouncer, consultez la Console d’administration.

Basculement de votre application pour utiliser PgBouncer

Pour commencer à utiliser PgBouncer, procédez comme suit :

Connectez-vous à votre serveur de base de données, mais utilisez le port 6432 au lieu du port 5432 classique. Vérifiez que cette connexion fonctionne.
```
psql "host=myPgServer.postgres.database.azure.com port=6432 dbname=postgres user=myUser password=myPassword sslmode=require"
```
Testez votre application dans un environnement d’assurance qualité sur PgBouncer pour vous assurer que vous n’avez pas de problème de compatibilité. Le projet PgBouncer fournit une matrice de compatibilité, et nous recommandons le regroupement de transactions pour la plupart des utilisateurs.
Modifiez votre application de production pour vous connecter au port 6432 au lieu de 5432. Surveillez les erreurs côté application susceptibles de pointer vers des problèmes de compatibilité.

PgBouncer en haute disponibilité redondant interzone

Dans les serveurs haute disponibilité redondant interzone, le serveur principal exécute PgBouncer. Vous pouvez vous connecter à PgBouncer sur le serveur principal sur le port 6432. Après un basculement, PgBouncer est redémarré sur le serveur de secours récemment promu, qui est maintenant le serveur principal. Par conséquent, la chaîne de connexion de votre application reste la même après le basculement.

Utilisation de PgBouncer avec d’autres pools de connexions

Dans certains cas, vous pouvez déjà disposer d’un pool de connexions côté application ou configurer PgBouncer côté application (par exemple, un sidecar Azure Kubernetes Service). Dans ce cas, la fonctionnalité PgBouncer intégrée peut toujours être utile, car elle offre les avantages de la mise à l’échelle des connexions inactives.

L’utilisation d’un pool côté application avec PgBouncer sur le serveur de base de données peut être bénéfique. Ici, le pool côté application offre l’avantage d’une latence de connexion initiale réduite (car l’aller-retour initial pour initialiser la connexion est beaucoup plus rapide), et le PgBouncer côté base de données fournit la mise à l’échelle des connexions inactives.

Limites

La fonctionnalité PgBouncer n’est actuellement pas prise en charge avec le niveau de calcul de serveur Burstable. Si vous modifiez le niveau de calcul d’Usage général ou Mémoire optimisée pour Burstable, vous perdez la capacité PgBouncer intégré.
Chaque fois que le serveur est redémarré pendant les opérations de mise à l’échelle, le basculement haute disponibilité ou un redémarrage, PgBouncer et la machine virtuelle sont également redémarrés. Vous devez ensuite rétablir les connexions existantes.
Le portail n’affiche pas tous les paramètres de PgBouncer. Après avoir activé PgBouncer et enregistré les paramètres, vous devez fermer le volet Paramètres du serveur (par exemple, sélectionnez Vue d’ensemble), puis revenir au volet Paramètres du serveur.
Vous ne pouvez pas utiliser les modes de pool d’instructions avec les instructions préparées. La version actuelle de PgBouncer a ajouté la prise en charge des instructions préparées dans le mode transactionnel. Cette prise en charge peut être activée et configurée via le paramètre max_prepared_statements. La définition de ce paramètre au-dessus de la valeur par défaut 0 active la prise en charge des instructions préparées. Cette prise en charge s’applique uniquement aux instructions préparées au niveau du protocole. Pour la plupart des langages de programmation, cela signifie que nous utilisons la fonction libpq PQprepare sur le client, en envoyant des commandes au niveau du protocole que PgBouncer peut intercepter, plutôt que d’émettre une commande SQL dynamique similaire à PREPARE PROC AS, qui envoie du texte que PgBouncer n’interprète pas correctement. Pour vérifier d’autres limitations du mode de pool choisi, reportez-vous à la documentation PgBouncer.
Si PgBouncer est déployé comme fonctionnalité, il devient un point de défaillance unique éventuel. En cas de panne de la fonctionnalité PgBouncer, l’ensemble du pool de connexions de base de données peut être perturbé et entraîner un temps d’arrêt de l’application. Pour atténuer le point de défaillance unique, vous pouvez configurer plusieurs instances PgBouncer derrière un équilibreur de charge à des fins de haute disponibilité sur des machines virtuelles Azure.
Restriction de taille de jeton avec l’authentification AAD : les utilisateurs disposant d’un grand nombre d’appartenances à un groupe ne pourront pas se connecter via PgBouncer en raison d’une restriction de taille de jeton. Les applications, services et utilisateurs avec un petit nombre de groupes fonctionnent.
PgBouncer est une application légère qui utilise une architecture à thread unique. Cette conception est idéale pour la plupart des charges de travail d’application. Toutefois, dans les applications qui créent un grand nombre de connexions de courte durée, cette conception peut affecter les performances de PgBouncer et limiter votre capacité à mettre à l’échelle votre application. Vous devrez peut-être essayer l’une des approches suivantes :
- Repartissez la charge de connexion sur plusieurs instances PgBouncer sur des machines virtuelles Azure.
- Envisagez d’autres solutions, y compris des solutions multithread telles que PgCat, sur des machines virtuelles Azure.

Important

Le paramètre pgbouncer.client_tls_sslmode pour la fonctionnalité PgBouncer intégrée a été dépréciée dans le serveur flexible Azure Database pour PostgreSQL.

Lorsqu’un protocole TLS/SSL pour des connexions à Azure Database pour PostgreSQL – Serveur flexible est appliqué en définissant le paramètre de serveur require_secure_transport sur ON, TLS/SSL est automatiquement appliqué pour les connexions à la fonctionnalité PgBouncer intégrée. Ce paramètre est activé par défaut lorsque vous créez une instance de serveur flexible Azure Database pour PostgreSQL et activez la fonctionnalité PgBouncer intégrée. Pour plus d’informations, consultez la vue d’ensemble de la mise en réseau pour le serveur flexible Azure Database pour PostgreSQL avec accès privé.

Pour les clients qui souhaitent une gestion simplifiée, une haute disponibilité intégrée, une connectivité facile avec des applications conteneurisées et la possibilité d’utiliser les paramètres de configuration les plus populaires, la fonctionnalité PgBouncer intégrée est un bon choix. Pour les clients qui souhaitent une scalabilité multithread, un contrôle total de tous les paramètres et une expérience de débogage, la configuration de PgBouncer sur des machines virtuelles Azure peut être une alternative.

Étapes suivantes

En savoir plus sur les concepts de réseau.
Obtenez une vue d’ensemble du serveur flexible Azure Database pour PostgreSQL.

Partager via