pgBouncer : un pooler simple, mais efficace

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
44
Mois de parution
octobre 2009
Spécialité(s)


Résumé

pgBouncer est un autre pooler de connexions. Contrairement à pgPool-II, il se contente d'être ça. Par contre, il va proposer des options uniques, comme une option permettant de préciser le moment où on souhaite changer de connexions. Cela ne sera pas forcément une connexion unique pour une session. Cela pourra être une connexion unique par transaction ou par instruction. Une option unique en son genre, mais qui a ses propres limitations.


Body

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.

debian1:~# wget http://ftp.fr.debian.org/debian/pool/main/p/pgbouncer/pgbouncer_1.3.1-1_i386.deb

debian1:~# wget http://ftp.fr.debian.org/debian/pool/main/libe/libevent/libevent-1.4-2_1.4.12-stable-1_i386.deb

debian1:~# dpkg -i libevent-1.4-2_1.4.12-stable-1_i386.deb pgbouncer_1.3.1-1_i386.deb

Sélection du paquet libevent-1.4-2 précédemment désélectionné.

(Lecture de la base de données... 22073 fichiers et répertoires déjà installés.)

Dépaquetage de libevent-1.4-2 (à partir de libevent-1.4-2_1.4.12-stable-1_i386.deb) ...

Sélection du paquet pgbouncer précédemment désélectionné.

Dépaquetage de pgbouncer (à partir de pgbouncer_1.3.1-1_i386.deb) ...

Paramétrage de libevent-1.4-2 (1.4.12-stable-1) ...

Paramétrage de pgbouncer (1.3.1-1) ...

pgbouncer daemon disabled in /etc/default/pgbouncer (warning).

Traitement des actions différées (« triggers ») pour « man-db »...

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 :

ERROR: no more connections allowed

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 :

max_client_conn + (max_pool_size * nombre_de_bases * nombre_d_utilisateurs)

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 :

d1db1 = host=debian1 dbname=db1

d1db2 = host=debian1 dbname=db2 user=u1

d2db1 = host=debian2 dbname=db1

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.

"user" "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 :

debian1:~# chown postgres:postgres /etc/pgbouncer/userlist.txt

debian1:~# chmod 600 /etc/pgbouncer/userlist.txt

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 :

[databases]

base1 = host=debian1 dbname=b1

base2 = host=debian2 dbname=b3

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

admin_users = postgres

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

"postgres" "postgres"

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

debian1:~# su - postgres

postgres@debian1:~$ psql -c "ALTER USER postgres PASSWORD 'postgres'"

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 :

debian1:~# su - postgres

postgres@debian1:~$ createdb b1

postgres@debian1:~$ createdb b2

postgres@debian1:~$ createdb b3

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

debian2:~# su - postgres

postgres@debian2:~$ createdb b3

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 :

host    all         all         192.168.10.66/32      trust

host    all         all         192.168.10.67/32      trust

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

listen_addresses = '*'

Maintenant, nous pouvons redémarrer PostgreSQL :

debian1:/etc/postgresql/8.4/main# /etc/init.d/postgresql-8.4 restart

Restarting PostgreSQL 8.4 database server: main.

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 :

START=1

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

debian1:~# pgbouncer -d /etc/pgbouncer/pgbouncer.ini

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 :

debian1:~# su - postgres

postgres@debian1:~$ psql -l

                                Liste des bases de données

    Nom    | Propriétaire | Encodage |     Tri     | Type caract. |    Droits d'accès

-----------+--------------+----------+-------------+--------------+-----------------------

b1        | postgres     | UTF8     | fr_FR.UTF-8 | fr_FR.UTF-8 |

b2        | postgres     | UTF8     | fr_FR.UTF-8 | fr_FR.UTF-8 |

b3        | postgres     | UTF8     | fr_FR.UTF-8 | fr_FR.UTF-8 |

postgres | postgres     | UTF8     | fr_FR.UTF-8 | fr_FR.UTF-8 |

template0 | postgres     | UTF8     | fr_FR.UTF-8 | fr_FR.UTF-8 | =c/postgres

                                                                  : postgres=CTc/postgres

template1 | postgres     | UTF8     | fr_FR.UTF-8 | fr_FR.UTF-8 | =c/postgres

                                                                  : postgres=CTc/postgres

(6 lignes)

postgres@debian1:~$ psql -p 6432 base1

psql: n'a pas pu se connecter au serveur : Aucun fichier ou répertoire de ce type

        Le serveur est-il actif localement et accepte-t-il les connexions sur la

        socket Unix « /var/run/postgresql/.s.PGSQL.6432 » ?

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

postgres@debian1:~$ /usr/sbin/pgbouncer /etc/pgbouncer/pgbouncer.ini

2009-08-29 12:10:50.469 2343 LOG File descriptor limit: 1024 (H:1024), max_client_conn: 100, max fds possible: 110

2009-08-29 12:10:50.480 2343 LOG listening on 127.0.0.1:6432

2009-08-29 12:10:50.483 2343 LOG listening on unix:/var/run/postgresql/.s.PGSQL.6432

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.

postgres@debian1:~$ psql -p 6432 base1

psql (8.4.0)

Saisissez « help » pour l'aide.

base1=#

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 :

base1=# \l

                                Liste des bases de données

    Nom    | Propriétaire | Encodage |     Tri     | Type caract. |    Droits d'accès

-----------+--------------+----------+-------------+--------------+-----------------------

b1        | postgres     | UTF8     | fr_FR.UTF-8 | fr_FR.UTF-8 |

b2        | postgres     | UTF8     | fr_FR.UTF-8 | fr_FR.UTF-8 |

b3        | postgres     | UTF8     | fr_FR.UTF-8 | fr_FR.UTF-8 |

postgres | postgres     | UTF8     | fr_FR.UTF-8 | fr_FR.UTF-8 |

template0 | postgres     | UTF8     | fr_FR.UTF-8 | fr_FR.UTF-8 | =c/postgres

                                                                  : postgres=CTc/postgres

template1 | postgres     | UTF8     | fr_FR.UTF-8 | fr_FR.UTF-8 | =c/postgres

                                                                  : postgres=CTc/postgres

(6 lignes)

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 :

base1=# SELECT datname, procpid, current_query FROM pg_stat_activity ;

datname | procpid |                         current_query

---------+---------+----------------------------------------------------------------

b1      |    2416 | select datname, procpid, current_query from pg_stat_activity ;

(1 ligne)

Le fichier de trace de pgBouncer l'indique aussi :

2009-08-29 12:19:11.687 2414 LOG C-0x95e68e0: base1/postgres@unix:6432 login successful: db=base1 user=postgres

2009-08-29 12:19:11.687 2414 LOG S-0x9603b18: base1/postgres@127.0.0.1:5432 new connection to server

La commande ps nous le confirme :

postgres@debian1:~$ ps -ef | grep "[b]1"

postgres 2416 2260 0 12:19 ?        00:00:00 postgres: postgres b1 127.0.0.1(38834) idle

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

postgres@debian1:~$ psql -p 6432 base1

psql (8.4.0)

Saisissez « help » pour l'aide.

base1=# CREATE TABLE t1 (id integer);

CREATE TABLE

base1=# INSERT INTO t1 SELECT i FROM generate_series(1, 1000) AS i;

INSERT 0 1000

base1=# SELECT * FROM t1 WHERE id BETWEEN 200 AND 205;

id

-----

200

201

202

203

204

205

(6 lignes)

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

base1=# \q

postgres@debian1:~$ ps -ef | grep "[b]1"

postgres 2416 2260 0 12:19 ?        00:00:00 postgres: postgres b1 127.0.0.1(38834) idle

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

postgres@debian1:~$ psql -p 6432 base1

psql (8.4.0)

Saisissez « help » pour l'aide.

base1=# SELECT datname, procpid, current_query FROM pg_stat_activity ;

datname | procpid |                         current_query

---------+---------+----------------------------------------------------------------

b1      |    2416 | select datname, procpid, current_query from pg_stat_activity ;

(1 ligne)

Maintenant, connectons-nous à base2 :

postgres@debian1:~$ psql -p 6432 base2

psql (8.4.0)

Saisissez « help » pour l'aide.

base2=# SELECT datname, procpid, current_query FROM pg_stat_activity ;

datname | procpid |                         current_query

---------+---------+----------------------------------------------------------------

b3      |    3954 | select datname, procpid, current_query from pg_stat_activity ;

(1 ligne)

Les traces de pgbouncer nous indiquent ceci :

2009-08-29 12:37:07.159 2414 LOG C-0x95e68e0: base2/postgres@unix:6432 login successful: db=base2 user=postgres

2009-08-29 12:37:07.160 2414 LOG S-0x9603c08: base2/postgres@192.168.10.67:5432 new connection to server

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 :

debian2:~# ps -ef | grep "[b]3"

postgres 3954 3865 0 12:39 ?        00:00:00 postgres: postgres b3 192.168.10.66(52401) idle

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.

postgres@debian1:~$ psql -p 6432 pgbouncer

psql (8.4.0, serveur 8.0/bouncer)

ATTENTION : psql version 8.4, version du serveur 8.0.

         Certaines fonctionnalités de psql pourraient ne pas fonctionner.

Saisissez « help » pour l'aide.

pgbouncer=#

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 :

pgbouncer=# SHOW HELP;

NOTICE: Console usage

DÉTAIL :

        SHOW HELP|CONFIG|DATABASES|POOLS|CLIENTS|SERVERS|VERSION

        SHOW STATS|FDS|SOCKETS|ACTIVE_SOCKETS|LISTS|MEM

        SET key = arg

        RELOAD

        PAUSE [<db>]

        SUSPEND

        RESUME [<db>]

        SHUTDOWN

SHOW

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 :

pgbouncer=# SHOW DATABASES;

   name    |     host      | port | database | force_user | pool_size | reserve_pool

-----------+---------------+------+-----------+------------+-----------+--------------

base1     | 127.0.0.1     | 5432 | b1        |            |        20 |            0

base2     | 192.168.10.67 | 5432 | b3        |            |        20 |            0

pgbouncer |               | 6432 | pgbouncer | pgbouncer |         2 |            0

(3 lignes)

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 :

pgbouncer=# SHOW POOLS;

database |   user    | cl_active | cl_waiting | sv_active | sv_idle | sv_used | sv_tested | sv_login | maxwait

-----------+-----------+-----------+------------+-----------+---------+---------+-----------+----------+---------

base1     | postgres |         2 |          0 |         0 |       0 |       1 |         0 |        0 |       0

base2     | postgres |         1 |          0 |         0 |       0 |       1 |         0 |        0 |       0

pgbouncer | pgbouncer |         1 |          0 |         0 |       0 |       0 |         0 |        0 |       0

(3 lignes)

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.

pgbouncer=# SHOW CLIENTS;

type |   user   | database | state | addr | port | local_addr | local_port |    connect_time     |    request_time     |    ptr    | link

------+----------+-----------+--------+------+------+------------+------------+---------------------+---------------------+-----------+------

C    | postgres | base1     | active | unix | 6432 | unix       |       6432 | 2009-08-29 13:34:58 | 2009-08-29 13:34:58 | 0x970f900 |

C    | postgres | base1     | active | unix | 6432 | unix       |       6432 | 2009-08-29 13:35:15 | 2009-08-29 13:35:15 | 0x970f9f0 |

C    | postgres | base2     | active | unix | 6432 | unix       |       6432 | 2009-08-29 13:35:29 | 2009-08-29 13:35:29 | 0x970fae0 |

C    | postgres | pgbouncer | active | unix | 6432 | unix       |       6432 | 2009-08-29 13:35:47 | 2009-08-29 13:39:45 | 0x970fbd0 |

(4 lignes)

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

pgbouncer=# SHOW STATS;

database | total_requests | total_received | total_sent | total_query_time | avg_req | avg_recv | avg_sent | avg_query

-----------+----------------+----------------+------------+------------------+---------+----------+----------+-----------

base1     |              0 |              0 |          0 |                0 |       0 |        0 |        0 |         0

base2     |              2 |             34 |        125 |            53994 |       0 |        0 |        1 |     26997

pgbouncer |              1 |              0 |          0 |                0 |       0 |        0 |        0 |         0

(3 lignes)

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.

 



Article rédigé par

Par le(s) même(s) auteur(s)

Installation de PostgreSQL

Magazine
Marque
Linux Pratique
Numéro
139
Mois de parution
septembre 2023
Spécialité(s)
Résumé

Nous commençons une série d’articles qui se veut être un guide du débutant pour l'installation, la maintenance et l'utilisation de PostgreSQL. Le but est de vous permettre de débuter rapidement sur de bonnes bases. Les articles couvriront l’installation et la configuration, mais aussi la mise en place de la sauvegarde, de la supervision, de la maintenance et de la réplication dans des cas simples. Ce premier article concerne donc l’installation.

Les derniers articles Premiums

Les derniers articles Premium

Quarkus : applications Java pour conteneurs

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Initié par Red Hat, il y a quelques années le projet Quarkus a pris son envol et en est désormais à sa troisième version majeure. Il propose un cadre d’exécution pour une application de Java radicalement différente, où son exécution ultra optimisée en fait un parfait candidat pour le déploiement sur des conteneurs tels que ceux de Docker ou Podman. Quarkus va même encore plus loin, en permettant de transformer l’application Java en un exécutable natif ! Voici une rapide introduction, par la pratique, à cet incroyable framework, qui nous offrira l’opportunité d’illustrer également sa facilité de prise en main.

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Les listes de lecture

9 article(s) - ajoutée le 01/07/2020
Vous désirez apprendre le langage Python, mais ne savez pas trop par où commencer ? Cette liste de lecture vous permettra de faire vos premiers pas en découvrant l'écosystème de Python et en écrivant de petits scripts.
11 article(s) - ajoutée le 01/07/2020
La base de tout programme effectuant une tâche un tant soit peu complexe est un algorithme, une méthode permettant de manipuler des données pour obtenir un résultat attendu. Dans cette liste, vous pourrez découvrir quelques spécimens d'algorithmes.
10 article(s) - ajoutée le 01/07/2020
À quoi bon se targuer de posséder des pétaoctets de données si l'on est incapable d'analyser ces dernières ? Cette liste vous aidera à "faire parler" vos données.
Voir les 122 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous