MIse à jour complète de la documentation et mise à niveau pour Debian 12

This commit is contained in:
emorino 2023-06-12 15:33:28 +02:00
parent 7b54834e72
commit 418297cde1

View file

@ -1,5 +1,3 @@
**Cette page a été importée automatiquement de notre ancien wiki mais n'a pas encore été révisée.**
## PgBouncer
<https://wiki.postgresql.org/wiki/PgBouncer>
@ -11,7 +9,7 @@ Pour PostgreSQL, accepter une nouvelle connexion est très coûteux en terme de
### Installation
~~~
# aptitude install pgbouncer
# apt install pgbouncer
~~~
### Configuration
@ -19,22 +17,26 @@ Pour PostgreSQL, accepter une nouvelle connexion est très coûteux en terme de
La configuration se fait dans le fichier _/etc/pgbouncer/pgbouncer.ini_.
* La section _[databases]_ doit contenir la liste des bases de données sur
lesquelles les clients pourront se connecter, avec une chaine de connexion
lesquelles les clients pourront se connecter, avec une chaîne de connexion
valide.
Par exemple :
~~~
[databases]
remotedb = dbname=db host=192.0.2.42 port=5433
* =
mydb = host=192.0.2.42 port=5432
~~~
Les connexions sur la base _remotedb_ 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.
* La section _[pgbouncer]_ contient différents paramètres pour le fonctionnement de PgBouncer. Les paramètres importants à modifier sont :
Les connexions sur la base _remotedb_ 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.
Si on veux que PgBouncer soit utilisé avec toutes les BDD, on peux le configurer en mode "wildcard" :
~~~
[databases]
* = host=192.0.2.42 port=5432
~~~
* La section _pgbouncer_ contient différents paramètres pour le fonctionnement de PgBouncer. Les paramètres importants à modifier sont :
* _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
@ -43,8 +45,60 @@ remotedb = dbname=db host=192.0.2.42 port=5433
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.
userlist.txt
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_
Voici la syntaxe du fichier d'authentification, en fonction des différents formats configuré par la variable `auth_file` :
~~~
"username1" "md5abcdef012342345"
"username2" "SCRAM-SHA-256$4096:gY9bPDkA8bA/bvpb8WyBAw==$22oqvA2nKmtlf1CCxJxf1iGcs5Atyqk1nbEjDbwrm7M=:czBfBzShQf0a9jmTtqVK1cEt1F7EAt+I6NEAzoEsChM="
~~~
On peux récupérer le hash du mot de passe d'un utilisateur SQL en faisant une requête sur la table `pg_shadow` comme ceci :
~~~
postgres=# select passwd from pg_shadow where usename='username2';
~~~
### Monitoring et administration
@ -64,6 +118,8 @@ pgbouncer=#
La requêtes `SHOW HELP;` permet de lister les requêtes possibles.
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**.
#### Voir les statistiques, connexions établies, etc…
~~~
@ -82,9 +138,33 @@ pgbouncer# show servers;
pgbouncer# show stats;
~~~
#### Opérations d'administration
#### Check NRPE
À tester et documenter
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 :
~~~
/usr/bin/check_postgres --action=pgb_pool_cl_active -H 127.0.0.1 -p 6432 --dbservice=pgbouncer -w 80 -c 350
~~~
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)
### FAQ