PgBouncer agit en tant que proxy entre des clients et un ou des serveurs PostgreSQL. Il permet de gérer un pool de connexion et est donc utile lorsque le client ne gère pas soit même son pool, notamment dans le cas de PHP.
Pour PostgreSQL, accepter une nouvelle connexion est très coûteux en terme de ressource car il va forquer un nouveau processus. PgPouncer permet donc de maintenir un pool de connexions actives auprès de PostgreSQL et de les rendre disponibles pour les clients voulant se connecter. PgBouncer a été conçu pour être très peu consommateur de ressources et pouvoir accepter un grand nombre de connexions (pas de fork ni de thread à chaque connexion, programmation évènementielle comme Nginx).
Les connexions sur la base _mydb_ seront renvoyées à l'hôte 192.0.2.42 sur le port 5433 et sur la base _db_. Toutes les autres seront renvoyées en local sur la base initialement demandée dans la requête.
* _pool_mode_ : permet de définir quand une connexion peut être
réattribuée (_session_ dans le cas d'une déconnexion explicite du
client (peu de gain de performance mais permet d'être complètement
transparent pour le client), _transaction_ lorsqu'une transaction est
terminée, _statement_ lorsque une requête est terminée (les
transactions ne peuvent alors plus être utilisées)) ;
* _max_client_conn_ : le nombre total de client qui peuvent être connectés simultanément à PgBouncer. Exemple : 5000
* _default_pool_size_ : le nombre total de client qui peuvent être connectés simultanément au serveur PostgreSQL derrière. Il ne faut pas dépasser le _max_connections_ du serveur en question moins une vingtaine (pour les connexions réservées au superadmin). Si _default_pool_size_ est dépassé (mais pas _max_client_conn_), alors les nouvelles connexions seront mises en attente.
* _auth_type_ : Permet de définir le type d'authentification utilisé par les utilisateurs SQL. Si la version de PostgreSQL est inférieure a la version 14, il faut utilisé par défaut le type "md5". Si la version de PostgreSQL est supérieure ou égale à la version 14, il faut utilisé par défaut le type "scram-sha-256".
* _listen_addr_ : Liste les ips sur lesquelles PgBouncer doit écouter, on peux mettre une liste d'ip séparé par une virgule.
Voici une configuration type de PgBouncer en PostgreSQL 15 / Debian 12 :
~~~
[databases]
* = host=192.0.2.42 port=5432
[pgbouncer]
logfile = /var/log/postgresql/pgbouncer.log
pidfile = /var/run/postgresql/pgbouncer.pid
listen_addr = 127.0.0.1
listen_port = 6432
unix_socket_dir =
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt
admin_users = pgbouncer_monitoring
stats_users =
# La connexion au serveur redevient libre lorsque le client termine une transaction
# Autres valeurs possibles : session (lorsque le client ferme la session), statement (lorsque la requête se termine)
pool_mode = transaction
# Nombre maximum de connexions entrantes
max_client_conn = 1000
# Nombre de connexion maintenues avec le serveur
default_pool_size = 100
# Ne pas enregistrer les connexions qui se passent bien
log_connections = 0
log_disconnections = 0
~~~
### Gestion des utilisateurs
PgBouncer a besoin de connaitre les identifiants des utilisateurs SQL, ceci se configure dans le fichier _/etc/pgbouncer/userlist.txt_
On peux définir un ou des utilisateurs "admin" pour PgBouncer, avec la variable **admin_users** et un ou des utilisateurs dédiés au statistiques avec la variable **stats_users**.
On peux utilisé le check_postgres pour monitorer les pools de connexions à PgBouncer.
Le check_pgbouncer est packager dans Debian depuis la version 10, on l'installe comme ceci :
~~~
# apt install check-postgres
~~~
Voici des exemples d'action qu'on peux utilisé pour monitoré PgBouncer :
* _pgb_pool_cl_active_ : Nombres sur l'état "client actif" établi entre un client et PgBouncer. Certains clients dans cet état exécutent des requêtes, mais d'autres peuvent ne pas le faire. Ça comprend deux "états", un "état" cl_active(EXECUTING) et un "état" cl_active(CONNECTED).
* _pgb_pool_cl_waiting_ : Le nombre affiché dans SHOW POOLS comme cl_waiting combine en fait le nombre de clients dans ces deux états. La connexion tombe dans l'état cl_waiting, lorsqu'une connexion entre pgbouncer et postgres a été faite, mais que lorsque la connexion a voulu entrer dans l'état _CL_ACTIVE(EXECUTING)_ ou CL_LOGIN(EXECUTING), mais que pgbouncer n'as trouver aucun backend postgres disponible, alors la connexion se mets dans l'état cl_waiting.
* _pgbouncer_sv_active_ : Nombres de connexion serveur active (c'est-à-dire de PgBouncer à Postgres), cela ne signifie pas nécessairement qu'il exécute activement une requête. La connexion au serveur restera active jusqu'à ce que le client connecté à PgBouncer se déconnecte explicitement.
Plusieurs autres type d'actions sont possible, voici la [documentation](https://www.pgbouncer.org/usage.html)
Voici un exemple de check_postgres qu'on met en place dans nrpe sur le serveur :
L'option `--dbservice` permet d'utilisé un fichier _.pg_service.conf_ pour l'authentification voir la [documentation](https://wiki.evolix.org/HowtoPostgreSQL#fichier-.pg_service.conf)