PgBouncer est un pooleur de connexions léger pour PostgreSQL.
PgBouncer 1.6 a été annoncé le 1er août 2015. Dans cet article de blog, nous parlerons des nouvelles améliorations majeures apportées à PgBouncer.
Principales nouvelles fonctionnalités de PgBouncer
Charger le hachage du mot de passe utilisateur à partir de la base de données postgres
PgBouncer permet désormais de charger le mot de passe de l'utilisateur depuis la base de données avec deux paramètres de configuration qui sont auth_user et auth_query .
- auth_user
Si auth_user est défini, tout utilisateur non spécifié dans auth_file sera interrogé à partir de pg_shadow dans la base de données à l'aide de auth_user. Le mot de passe de Auth_user sera extrait de auth_file. Ce paramètre peut également être défini par base de données. - auth_query
Ce paramètre nous permet d'écrire une requête SQL pour charger le mot de passe de l'utilisateur à partir de la base de données. Il s'exécute sous auth_user.Voir la requête par défaut ci-dessous :SELECT usename, passwd FROM pg_shadow WHERE usename=$1
Le mode de regroupement peut être configuré à la fois par base de données et par utilisateur
Grâce à cette fonctionnalité, indépendamment du mode de regroupement principal, les clients peuvent désormais se connecter à différentes bases de données avec l'un des 3 modes de regroupement décrits ci-dessous. Ceci s'applique également aux utilisateurs. Par exemple, si le mode de regroupement est le regroupement de sessions, un utilisateur spécifique peut être configuré pour utiliser le regroupement de transactions. Cela nous donne une flexibilité au niveau de la base de données et au niveau de l'utilisateur pour appliquer des options de regroupement plus appropriées.
PgBouncer propose 3 modes de regroupement de connexions :
- Regroupement de sessions
Pendant la durée de vie d'une connexion client, une connexion serveur existante est attribuée au client et après la déconnexion du client, la connexion serveur attribuée est remise dans le pool de connexions. - Regroupement des transactions
Dans ce mode, une connexion serveur n'est pas attribuée immédiatement à un client connecté, mais uniquement lors d'une transaction. Dès que la transaction est terminée, la connexion est remise dans le pool. - Regroupement des déclarations
Ceci est similaire à la mise en commun des transactions, mais est plus agressif. Un backend est affecté chaque fois qu'une requête à instruction unique est émise. Lorsque l'instruction est terminée, la connexion est remise dans le pool.
Limites de connexion par base de données et par utilisateur :max_db_connections et max_user_connections
Avec cette fonctionnalité, nous pouvons maintenant contrôler également les limites de connexion par base de données/niveau utilisateur avec les deux nouveaux paramètres, qui sont max_db_connections et max_user_connections .
- max_db_connections
Ce paramètre n'autorise pas plus que les connexions spécifiées par base de données (quel que soit le pool, c'est-à-dire l'utilisateur).
La valeur par défaut de ce paramètre est illimitée. - max_user_connections
Ce paramètre n'autorise pas plus que les connexions spécifiées par utilisateur (quel que soit le pool - c'est-à-dire l'utilisateur).
Ajouter des commandes DISABLE/ENABLE pour empêcher de nouvelles connexions
Avec cette fonctionnalité, PgBouncer a ENABLE/DISABLE db ; commandes pour empêcher de nouvelles connexions.
- DÉSACTIVER la base de données ;
Cette commande rejette toutes les nouvelles connexions client sur la base de données donnée. - ACTIVER la base de données ;
Cette commande autorise les nouvelles connexions client après un précédent DISABLE commande.
Nouveau backend DNS préféré :c-ares
c-ares est le seul backend DNS qui prend en charge toutes les fonctionnalités intéressantes :/etc/hosts avec actualisation, recherche SOA, réponses volumineuses (via TCP/EDNS+UDP), IPv6. C'est le backend préféré maintenant, et sera probablement le seul backend à l'avenir.
Les fichiers de configuration ont la directive '%include FILENAME' pour permettre à la configuration d'être divisée en plusieurs fichiers
Avec cette fonctionnalité, PgBouncer prend en charge l'inclusion de fichiers de configuration dans d'autres fichiers de configuration.
En d'autres termes, le fichier de configuration de PgBouncer peut contenir des directives d'inclusion, qui spécifient un autre fichier de configuration à lire et à traiter. Cela permet de diviser un gros fichier de configuration en fichiers plus petits et plus faciles à gérer. Les directives d'inclusion ressemblent à ceci :
%include filename
Si le nom du fichier n'est pas un chemin absolu, il est considéré comme relatif au répertoire de travail actuel.
Il y a plus de fonctionnalités publiées dans cette version. Vous pouvez visiter la page du journal des modifications de PgBouncer ou consulter la liste ci-dessous pour les autres améliorations :
- Afficher remote_pid dans SHOW CLIENTS/SERVERS. Disponible pour les clients qui se connectent via des sockets unix et des serveurs de socket tcp et unix. Dans le cas de tcp-server, le pid est extrait de la clé d'annulation.
- Ajouter un paramètre de configuration distinct (dns_nxdomain_ttl) pour contrôler la mise en cache DNS négative.
- Ajoutez l'adresse IP et le port de l'hôte client à nom_application. Ceci est activé par un paramètre de configuration application_name_add_host qui par défaut est "off".
Qu'est-ce que PgBouncer ?
PgBouncer est un utilitaire de gestion des connexions client à la base de données PostgreSQL. En un mot, il maintient un pool de connexions au serveur PostgreSQL et réutilise ces connexions existantes. Bien que cela puisse être utile pour réduire la surcharge de connexion client, cela permet également de limiter le nombre maximal de connexions ouvertes au serveur de base de données. Il peut également être utilisé pour la mise en forme du trafic, comme la redirection des connexions vers une ou plusieurs bases de données vers différents serveurs de base de données. En plus de cela, PgBouncer peut être utilisé pour gérer la sécurité au niveau de l'utilisateur et même au niveau de la base de données.
Voir le schéma ci-dessous qui décrit l'architecture de PgBouncer de manière plus visuelle.
Dans cet exemple particulier, les applications clientes sont connectées à des instances PgBouncer distinctes où elles seraient plutôt connectées directement aux serveurs de base de données PostgreSQL. Les serveurs de base de données "DB Server 1" et "DB Server 2" peuvent être des instances PostgreSQL indépendantes ou ils peuvent faire partie d'un cluster avec différents rôles (par exemple, maître/réplica ou écriture-maître/sauvegarde-maître, etc.).
Chaque instance de PgBouncer maintient un pool de connexions avec un certain nombre de connexions ouvertes aux serveurs PostgreSQL. Comme on peut le voir dans l'exemple, PgBouncers permet de créer des pools avec des connexions à différentes bases de données et même des connexions à différents serveurs de bases de données.
Pour plus d'informations
Vous pouvez visiter le site Web principal de PgBouncer : http://pgbouncer.github.io/
Ils ont une belle page FAQ : http://pgbouncer.github.io/faq.html
Vous pouvez consulter le dépôt Github du projet : http://github.com/pgbouncer/pgbouncer
