Exploitation

Exécution d’une instance

Une instance de PostgreSQL correspond à l’exécution d’un processus postgres. Ce processus accueille les connexions des clients et ouvre un nouveau processus postgres pour chaque connexion réussie. D’autres processus postgres sont lancés au démarrage par le processus parent, pour différentes tâches. Un processus a la charge de l’écriture des données, et un autre celle de la récupération des statistiques, comme dans le résultat de la commande ps suivante :

$ ps fx   
32460 ?        S      0:01 /usr/lib/postgresql/10/bin/postgres -D 
/var/lib/postgresql/10/main -c 
config_file=/etc/postgresql/10/main/postgresql.conf 
32462 ?        Ss     0:00  \_ postgres: 10/main: checkpointer process 
32463 ?        Ss     0:00  \_ postgres: 10/main: writer process 
32464 ?        Ss     0:00  \_ postgres: 10/main: wal writer process 
32465 ?        Ss     0:01  \_ postgres: 10/main: autovacuum launcher 
process 
32466 ?        Ss     0:01  \_ postgres: 10/main: stats collector process
32467 ?        Ss     0:00  \_ postgres: 10/main: bgworker: logical 
replication launcher ...

Administration du serveur

Gestionnaire de connexions

Le gestionnaire de connexions travaille entre les applications clientes et le serveur de bases de données. Sa principale tâche est de gérer l’ouverture des connexions au serveur de bases de données à la place des applications clientes. Cette gestion va, de fait, maintenir les connexions ouvertes dans le serveur de bases de données, et permettre aux applications clientes de les réutiliser plus facilement. De fait, cette gestion d’un réservoir de connexions permet d’économiser le temps d’ouverture d’une connexion au serveur de bases de données, et donc d’économiser des ressources. En effet, l’ouverture d’une connexion dans PostgreSQL entraîne la création d’un nouveau processus, qui est une opération coûteuse. Cette économie de ressources, et donc de temps, permet une meilleure montée en charge des applications utilisant un serveur de bases de données PostgreSQL.

Le gestionnaire de connexions peut être executé dans un système indépendant de celui où fonctionne le serveur de bases de données. Il n’existe pas de règle toute faite, le choix se fait en fonction de la topologie existante entre les applications clientes et les serveurs de bases données, et en fonction de la résilience souhaitée de l’ensemble. Par exemple, si l’on souhaite que le gestionnaire de bases de données participe aux mécanismes de haute disponibilité de l’application, il est opportun de ne pas l’éxécuter dans le même système que le serveur de bases de données, mais plutôt dans le système où fonctionnent les applications clientes.

Certains serveurs d’applications intègrent de fait un gestionnaire de connexions, comme J2E ou Node.js, ce qui rend inutile l’adoption d’un tel outil. À l’inverse, les langages, par exemple PHP, n’intégrant pas cette fonctionnalité, bénéficeront de ces outils.

Sauvegardes et restauration

Il existe deux méthodes de sauvegarde des données avec PostgreSQL. La première est la sauvegarde logique se situant au niveau des objets contenus dans la base de données, et dont le résultat consiste en un ensemble d’instructions permettant de reconstituer les objets et les données. La deuxième est la sauvegarde physique se situant au niveau des fichiers, ignorant complètement le sens des données contenues, mais permettant une grande finesse de restauration, en termes d’évolution dans le temps.

Exploitation et tâches de maintenance

Une fois la base de données installée et les applications connectées, il est nécessaire de suivre l’activité de l’instance. En effet, une base de données évolue dans le temps, notamment avec les insertions de données, les mises à jour et les suppressions de données.

Il est nécessaire de comprendre son fonctionnement et de réagir en conséquence.

EXPLAIN  <options> requete ;
 

( ANALYZE <booléen>, BUFFERS <booléen>, COSTS <booléen>, 
TIMING <booléen>,FORMAT { TEXT | XML | JSON | YAML } )
 

clients=# EXPLAIN SELECT * FROM prestations  
where prest_id = 32 ;  
                         QUERY...

Test de l’installation avec pgbench

L’utilitaire pgbench, qui est livré dans les contributions de PostgreSQL, permet de tester une installation en évaluant un nombre de transactions par seconde. Ceci permet ainsi de mesurer les améliorations apportées par un changement dans la configuration.

Il utilise une base de données, dans laquelle il crée des tables et les remplit avec des données, dont la quantité est précisée à l’initialisation. Puis, lors de la phase de test, pgbench envoie des transactions et compte le nombre de transactions par seconde, en fonction de différents paramètres comme le nombre de connexions ou le nombre de transactions concurrentes.

Les tests peuvent se dérouler dans une base de données dédiée, nommée pgbench créée avec la commande suivante :

[postgres] $ createdb pgbench
 

Puis, la commande suivante permet d’initialiser la base pour les tests :

[postgres] $ pgbench -i -s 10 pgbench
 

L’option -i active l’initialisation et l’option -s est un facteur multipliant, permettant d’insérer plus de données, ici avec un facteur 10.

Ensuite, le test peut être lancé avec la commande suivante :

[postgres] $ pgbench -c 10 -t 30 pgbench  
starting vacuum...end.  
transaction type: TPC-B (sort of)  
scaling factor: 10  
number of clients:...

Exploitation des traces d’activités avec pgBadger

Le logiciel pgBadger est un script Perl permettant d’analyser le contenu des fichiers de traces d’activité, pour en extraire des données statistiques. Ceci permet d’évaluer le comportement de PostgreSQL, par exemple le nombre d’ordres d’insertion ou de mise à jour.

$ tar xf pgbadger-6.2.tar.gz  
$ cd pgbadger-6.2  
$ perl Makefile.PL  
$ make && sudo make install