pgBouncer : un pooler simple, mais efficace

En dehors de cette fonctionnalité très particulière, pgBouncer a d'autres qualités. Il est remarquablement léger. Son utilisation de la mémoire est très faible. Le fait de ne pas être aussi un système de réplication et un outil de répartition de charge l'aide à être très petit.

De plus, il n'est pas lié à un seul serveur. La configuration permet d'indiquer le ou les serveurs qui hébergent telle ou telle base.

1. Pré-requis

Comme pgBouncer ne supporte que la version 3 du protocole de communication de PostgreSQL, vous devez utiliser une version 7.4 ou ultérieure. Ceci tombe très bien vu qu'il s'agit de la version la plus ancienne encore maintenue par les développeurs de PostgreSQL. Donc, si vous avez une version plus ancienne, commencez par mettre à jour PostgreSQL. Puis, testez pgPool-II et pgBouncer pour choisir celui qui vous convient.

2. Installation

pgBouncer dispose d'un paquet pour Debian, mais ce dernier est pour la version Sid. Néanmoins, il est possible de l'installer sur une Etch. pgBouncer utilise libevent et il en faut une version particulièrement à jour. Donc, nous utiliserons aussi la version Sid de cette bibliothèque.

Et voilà, installation terminée. Passons à la configuration.

3. Configuration de pgBouncer

Le fichier de configuration de pgBouncer se trouve par défaut dans le répertoire /etc/pgbouncer. Il se nomme pgbouncer.ini. Son extension nous indique qu'il se paramètre comme tout autre fichier .ini (un format de fichier de configuration plus connu sous Windows que sous Linux). Donc, pour ceux qui n'en ont jamais vu, un fichier .ini peut comporter des commentaires. Ces derniers commencent toujours avec un point-virgule. Il est possible de déclarer des sections en plaçant un ou plusieurs mots entre crochets.

D'ailleurs, ce fichier comprend deux sections :

- databases, qui sert à déclarer toutes les bases de données qui seront utilisables à partir de pgBouncer ;

- pgbouncer, qui permet de configurer des paramètres généraux.

Commençons par les paramètres généraux.

Les trois premiers permettent d'indiquer sur quelles interfaces (listen_addr), sur quel port (listen_port), ainsi que sur quel socket (unix_socket_dir) le serveur pgbouncer va attendre les connexions. Par défaut sur Debian, pgBouncer écoute sur le port 6432 de l'interface locale et sur la socket stockée dans le répertoire /var/run/postgresql.

Contrairement à pgPool-II, la méthode d'authentification est fixe. Ce sera soit any, soit trust, soit plain, soit crypt, soit md5. Notre conseil est plutôt d'utiliser md5, bien que la méthode par défaut soit trust. Any est spécifique à pgBouncer : dans ce cas, même le nom de l'utilisateur n'est pas vérifié. Toujours pour l'authentification, il est possible de fournir une liste d'utilisateurs et de mots de passe dans un fichier dont le chemin complet sera indiqué avec le paramètre auth_file.

pgBouncer permet d'accéder à une base de données virtuelle. Son but est de fournir des informations sur le paramétrage actuel, mais aussi des statistiques sur les accès passés et présents. Évidemment, l'accès à cette base est protégé. Le paramètre admin_users permet de préciser les utilisateurs qui sont autorisés à lire et à modifier, alors que le paramètre stats_users indique les utilisateurs qui ne peuvent que consulter les statistiques.

pool_mode précise le mode de gestion des connexions. pgBouncer est capable de faire en sorte qu'une session se passe entièrement sur une seule connexion (mode session). Le mode transaction permet de changer de connexion à chaque nouvelle transaction, implicite ou explicite. Enfin, le mode statement change de connexion à chaque instruction, ce qui interdit l'usage des transactions explicites.

Il est possible de préciser une ou plusieurs requêtes à exécuter avant de changer de connexion. Ces requêtes doivent être enregistrées dans le paramètre server_reset_query.

La configuration des limites de connexion est un peu particulière avec pgBouncer. max_client_conn indique le nombre maximum de connexions possibles via pgBouncer, quelle que soit les bases de données ou le serveur PostgreSQL concerné. pgBouncer ne gèrera pas plus que ce nombre de connexions clients/pgBouncer. Si vous essayez de dépasser ce nombre, vous obtiendrez le message suivant :

default_pool_size est le nombre maximum de connexions pgBouncer/PostgreSQL pour un pool (nous verrons plus tard qu'un pool est lié à une base de données côté pgBouncer). Il est à savoir que ce nombre est configurable en général s'il se trouve dans la section pgbouncer. Il est possible de personnaliser sa configuration pool par pool avec la section databases.

pgBouncer utilise des descripteurs de fichiers pour les connexions. Le nombre de descripteurs peut être bien plus important que ce qu'autorise par défaut le système d'exploitation. Le maximum théorique est de :

Le cas échéant, ulimit vous permettra de configurer le nombre de descripteurs disponibles sur votre système d'exploitation Linux.

Le paramètre logfile indique le fichier où sont enregistrées toutes les traces de pgBouncer. Vous pouvez demander de tracer les connexions (paramètre log_connections), les déconnexions (log_disconnections) et enfin demander l'envoi des erreurs du pooler au client (log_pooler_errors).

La configuration de certains délais est possible :

- server_lifetime permet de terminer une connexion au serveur PostgreSQL si elle a duré plus que ce temps en secondes (1200 par défaut, soit 20 minutes).

- server_idle_timeout termine une connexion au serveur si elle n'a pas été utilisée pendant cette période de temps (60 secondes par défaut).

- server_connect_timeout annule une tentative de connexion si le serveur n'a pas répondu durant ce laps de temps (15 secondes par défaut).

- server_login_retry ajoute un délai après un échec de connexion (là aussi, 15 secondes par défaut).

- query_timeout annule une requête si cette dernière ne renvoie pas le résultat pendant ce temps en seconde (fonctionnalité désactivée par défaut, car considérée comme dangereuse).

- client_idle_timeout ferme une connexion s'il n'y a aucune activité sur cette connexion pendant ce délai (fonctionnalité désactivée par défaut car considérée comme dangereuse).

- client_login_timeout déconnecte un client qui n'a pas réussi à s'authentifier après s'être connecté pendant ce laps de temps en seconde (60 par défaut).

Comme vous pouvez le voir, pgPool-II et pgBouncer partagent un bon nombre d'options. Leur nom change parfois, mais il est quand même assez facile de s'y retrouver. La vraie grosse différence tient dans la section des bases de données.

En effet, alors que pgPool-II permet d'indiquer un serveur sur lequel tous les clients iront se connecter via le démon pgpool, pgBouncer va permettre de spécifier des bases de données. Ces dernières pourront faire partie du même serveur PostgreSQL ou de plusieurs serveurs PostgreSQL. Cela donne des possibilités très intéressantes.

La section databases permet de définir un ensemble de bases de données. Le nom du paramètre sera le nom de la base de données que le client devra utiliser pour se connecter. Cela correspondra ou non au nom de la base de données réelle. La valeur de ce paramètre sera un ensemble de paramètres indiquant où se connecter : adresse IP du serveur, port TCP/IP, nom de la base (optionnel), nom de l'utilisateur (optionnel). Il est aussi possible d'y ajouter quelques paramètres de configuration du pool. Voici la liste des paramètres possibles :

- host, adresse IP du serveur PostgreSQL ;

- port, port TCP/IP pour la connexion au serveur PostgreSQL ;

- dbname, nom de la base de données ;

- user, nom de l'utilisateur ;

- password, mot de passe de l'utilisateur ;

- pool_size, taille du pool pour cette base de données ;

- connect_query, requête à exécuter au moment de la connexion ;

- client_encoding, datestyle, timezone, paramètres PostgreSQL pouvant être surchargés par pgBouncer.

Voici un exemple de configuration :

Avec cette configuration, si un utilisateur se connecte sur pgBouncer en demandant une connexion à la « base » d1db1, il sera mis en relation avec la base db1 sur le serveur debian1. S'il demande une connexion à la « base » d1db2, il sera connecté sur la base db2 du serveur debian1 en tant qu'utilisateur u1. Enfin, s'il demande une connexion à la « base » d2db1, il sera en fait connecté à la base db1 du serveur debian2.

L'idée comme quoi le client indique un nom de base qui lui permettra de se connecter sur différents serveurs PostgreSQL, différentes bases de données, avec un paramétrage qui peut être personnalisé est très puissante. Elle peut aussi être source de confusion pour les nouveaux utilisateurs.

Maintenant, attaquons-nous à la configuration de pgBouncer et de PostgreSQL pour montrer l'utilisation de ce pooler de connexions.

4. Configuration des utilisateurs

Avant de lancer la connexion vers PostgreSQL, pgBouncer vérifie le couple utilisateur/mot de passe. Pour cela, la configuration permet d'indiquer le chemin complet vers un fichier contenant une liste des utilisateurs et de leurs mots de passe. Le format est simple : le nom de l'utilisateur suivi d'un espace, suivi du mot de passe.

Étrangement, les guillemets sont nécessaires. Sans eux, le fichier est déclaré invalide.

Vu que les mots de passe sont directement dans ce fichier, il est conseillé, voire requis, de modifier le propriétaire et les droits du fichier. Sous Debian, nous nous trouvons avec un fichier appartenant à root (pourquoi pas...), mais avec les droits 644, ce qui fait que tout le monde peut lire ce fichier. Pensez donc toujours à vérifier le propriétaire et les droits de ce fichier, et modifiez-les le cas échéant, d'autant plus si vous utilisez le mode trust pour lequel les mots de passe apparaissent en clair :

Il est à savoir qu'il est aussi possible d'utiliser le fichier des utilisateurs de PostgreSQL. Ce fichier n'est jamais modifié manuellement. PostgreSQL le met à jour quand il reçoit une requête d'ajout d'un utilisateur ou de modification de mot de passe. Évidemment, cela suppose que le serveur PostgreSQL se trouve sur le même serveur physique que pgBouncer. L'intérêt est que tout nouvel utilisateur ajouté dans PostgreSQL se trouve immédiatement déclaré au niveau de pgBouncer.

5. Configuration rapide de pgBouncer

Nous allons autoriser la connexion à deux bases de données, sur deux serveurs différents. Voici le contenu de la section databases :

Dans la section pgbouncer, nous allons simplement ajouter un utilisateur dans la liste des administrateurs :

En ce qui concernent les utilisateurs, il nous faut ajouter l'utilisateur postgres dans le fichier /etc/pgbouncer/userlist.txt :

Ensuite, il faut ajouter le mot de passe à cet utilisateur :

6. Configuration de PostgreSQL

Pour les besoins du test, nous allons créer trois bases de données sur debian1, de nom b1, b2 et b3 :

Nous n'allons en créer qu'une sur debian2 :

Comme pgBouncer va se connecter en TCP/IP sur les deux serveurs PostgreSQL, nous devons modifier le fichier de configuration pg_hba.conf pour autoriser les accès. Ce dernier devra contenir les deux lignes suivantes :

Il ne nous reste plus qu'à modifier le fichier postgresql.conf pour que le serveur PostgreSQL écoute sur toutes les interfaces réseau :

Maintenant, nous pouvons redémarrer PostgreSQL :

7. Lancement

Debian dispose d'un script de démarrage. Pour que ce dernier s'exécute au démarrage du serveur, il est nécessaire de faire une légère modification dans le fichier /etc/default/pgbouncer. Il faut passer la variable START à 1 :

Pour les autres, il est possible de démarrer pgBouncer manuellement de cette façon :

L'option -d indique à pgBouncer de fonctionner en mode démon. Le fichier indiqué est le fichier de configuration avec son chemin complet.

8. Utilisation

PostgreSQL lancé mais pgBouncer arrêté, nous avons le même souci qu'avec pgPool-II :

Il n'est pas possible de se connecter à base1. Lançons maintenant pgBouncer :

Attention, tout comme PostgreSQL, pgBouncer refuse de s'exécuter sous le compte root. Le mieux dans ce cas est d'utiliser le compte postgres.

La connexion s'est bien faite. Psql affiche le nom base1, car il utilise ce qui lui a été fourni en ligne de commande. Mais, en fait, nous ne sommes pas connectés à base1 vu que cette base n'existe pas :

La base base1 n'existe que dans le fichier de configuration de pgBouncer, qui nous a re-routé vers la base db1 de debian1, comme le montre le résultat de la requête suivante :

Le fichier de trace de pgBouncer l'indique aussi :

La commande ps nous le confirme :

Nous pouvons lancer toutes les requêtes SQL que nous voulons. Elles seront exécutées sur cette base b1 :

Remarquez aussi que, si on quitte psql, la connexion est maintenue par pgBouncer :

Et si nous nous reconnectons après coup, nous nous retrouvons sur la même connexion :

Maintenant, connectons-nous à base2 :

Les traces de pgbouncer nous indiquent ceci :

Bien que nous nous soyons connecté sans indiquer de serveur, pgBouncer a vu dans sa configuration que base2 correspond à la base de données b3 sur le serveur debian2 et a lancé la connexion adéquate.

Du coup, on ne voit la connexion que sur debian2 :

9. Console d'administration de pgBouncer

L'un des points forts de pgBouncer est la disponibilité d'une console. Pour en profiter, il faut se connecter à la base de données virtuelle pgbouncer en tant qu'un des utilisateurs listés dans les paramètres admin_users et stats_users.

Le message d'avertissement est normal. pgBouncer agit comme un serveur PostgreSQL lorsque nous nous connectons à la base pgbouncer. La version utilisée par les développeurs de pgBouncer est justement en 8.0. Nous nous connectons donc avec une version 8.4 de psql sur un serveur 8.0, d'où le message d'avertissement de psql que vous pouvez tranquillement ignorer.

Toutes les fonctionnalités accessibles via cette console sont listées par la commande SHOW HELP :

Nous n'allons pas les voir toutes, mais regardons néanmoins les principales. SHOW DATABASES indique la liste des bases de données avec leur configuration :

On peut ainsi voir qu'il ne peut pas y avoir plus de deux connexions sur la base pgbouncer et que l'utilisateur est forcé à pgbouncer.

SHOW POOLS va indiquer la liste des pools configurés et quelques autres informations statistiques :

Les statistiques indiquent notamment le nombre de clients actifs et en attente, le nombre de connexions serveur actives, en attente, utilisées, et ainsi de suite.

La commande SHOW CLIENTS affiche la liste des clients connectés à pgbouncer. La dernière que nous allons montrer est SHOW STATS :

Elle affiche des statistiques sur les différentes bases : nombre de requêtes, temps d'exécution, etc. Cela peut fournir des informations capitales sur l'utilisation des connexions via pgBouncer.

Sachez qu'il est aussi possible de contrôler pgBouncer à partir de cette console. Vous avez accès aux actions suivantes :

- PAUSE, pour que pgBouncer tente une déconnexion de tous les serveurs PostgreSQL, une fois que les requêtes ont terminé leur exécution ;

- SUSPEND, pour vider tous les tampons des sockets et pour que pgBouncer arrête d'écouter les sockets ;

- RESUME, pour recommencer le travail après une commande PAUSE ou SUSPEND ;

- SHUTDOWN, pour arrêter tout simplement le processus pgbouncer ;

- RELOAD, pour demander au processus de recharger son fichier de configuration.

10. Quelques astuces

Contrairement à pgPool-II, pgBouncer ne propose pas de répartition de charge. Le seul moyen d'en avoir un est d'utiliser un répartiteur de charge de connexion TCP, comme LVS ou HAProxy.

De même, il est impossible de se connecter en SSL avec pgBouncer. Néanmoins, l'outil Stunnel gère le protocole PostgreSQL depuis la version 4.27. N'hésitez pas à le tester.

Conclusion

Bien que pgBouncer fasse beaucoup moins de choses que pgPool-II, cela ne l'empêche pas d'être un outil très intéressant. Sa console d'administration permet d'obtenir de nombreuses statistiques très intéressantes, autorisant du coup une surveillance très poussée de cet outil.

Le fait qu'il soit capable de gérer des connexions vers différents serveurs est un plus très agréable. Cela se révèle très utile quand on dispose de deux serveurs PostgreSQL, une moitié des bases dont le maître est le serveur 1 et l'autre moitié le serveur 2. Le switchover et le failover s'en trouvent facilités.

Encore une fois, la documentation est très restreinte, mais il faut bien avouer que pour un produit comme pgBouncer, cela a relativement peu d'importance.