18
0
Fork 0

Descente d'un # dans la hiérarchie du sommaire

This commit is contained in:
whirigoyen 2022-02-28 15:16:31 +01:00
parent bbab6f3bd0
commit 918c836508
1 changed files with 78 additions and 55 deletions

View File

@ -9,7 +9,8 @@ categories: databases
[PostgreSQL](https://www.postgresql.org/) est un système de gestion de base de données relationnelle et objet. PostgreSQL met l'accent sur le respect du standard SQL et l'intégrité des données, notamment avec le mécanisme des journaux de transactions (WAL : Write Ahead Logging) écrits sur le disque avant un enregistrement réél dans les fichiers de base de données.
## Installation
# Installation
~~~
# dpkg-reconfigure locales
@ -36,7 +37,7 @@ Ver Cluster Port Status Owner Data directory Log file
> *Note* : il faut s'assurer d'avoir configuré sa locale système `dpkg-reconfigure locales` avant installation car l'initialisation des bases de données est faite avec la locale du système.
### Installation via apt.postgresql.org
## Installation via apt.postgresql.org
Le dépôt **apt.postgresql.org** permet d'installer des versions différentes de PostgreSQL, ainsi que plusieurs extensions. C'est maintenu par le *PostgreSQL Global Development Group (PGDG)* qui rassemble plusieurs développeurs Debian.
@ -72,9 +73,10 @@ Ver Cluster Port Status Owner Data directory Log file
11 main 5432 online postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
~~~
## Administration basique
### Lister les instances existantes
# Administration basique
## Lister les instances existantes
~~~
# pg_lsclusters
@ -84,7 +86,8 @@ Ver Cluster Port Status Owner Data directory Log file
11 main 5433 online postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
~~~
### Lister les requêtes actives
## Lister les requêtes actives
Pour PostgreSQL >= 9.2 :
@ -106,7 +109,8 @@ $ psql
postgres=# SELECT * FROM pg_stat_activity WHERE current_query!='<IDLE>';
~~~
### psql
## psql
Voici quelques astuces utilisables en ligne de commande `psql` :
@ -121,7 +125,8 @@ postgres=# \timing on : affiche le temps d'exécution des requêtes
postgres=# \! commande : permet dexécuter des commandes shell, ex: \! mkdir /home/foo/bar
~~~
### pg_top
## pg_top
~~~
# apt install ptop
@ -160,7 +165,8 @@ t - Toggle between cumulative or differential statistics when viewing
u - display processes for only one user (+ selects all users)
~~~
## Configuration
# Configuration
Fichiers de configuration :
@ -186,7 +192,7 @@ On verra dans ce cas les changements dans les logs :
~~~
## Instances PostgreSQL
# Instances PostgreSQL
Une surcouche Debian permet de gérer simplement plusieurs versions et plusieurs instances d'une même version de PostgreSQL. Cela permet entre autre de faciliter les migrations d'une version majeure à une autre.
@ -227,7 +233,7 @@ On peut remarquer que toute l'arborescence est organisée en fonction des versio
* etc…
## Gestion des utilisateurs et permissions
# Gestion des utilisateurs et permissions
PostgreSQL permet de lier un utilisateur Unix à un utilisateur PostgreSQL. C'est le cas pour l'utilisateur *postgres* (superadmin PostgreSQL), qui est lié à l'utilisateur Unix *postgres*.
Ainsi pour passer superadmin PostgreSQL :
@ -257,7 +263,8 @@ Bien s'assurer que les utilisateurs PostgreSQL ont un mot de passe de défini av
Pour plus de détails on pourra consulter la [documentation](https://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html).
### pgpass
## pgpass
Pour se connecter plus facilement à postgresql (avec `psql` mais aussi `pgdump` etc), on peut utiliser le fichier `~/.pgpass` avec comme format :
@ -268,7 +275,7 @@ hostname:port:database:username:password
> *Note* : Ce fichier doit avoir des droits en _600_ et on peux utilisé des wilcards '*' pour autorisés le ou les champs souhaitez.
### Fichier .pg_service.conf
## Fichier .pg_service.conf
Pour se connecter a différentes instances postgresql, en local ou distante, à la racine de l'utilisateur postgres, créer un fichier .pg_service.conf comme ceci :
@ -281,7 +288,8 @@ user=role_pg
password=bar
~~~
## Optimisation
# Optimisation
La configuration par défaut est faite pour s'adapter à toutes sortes de machines, elle n'est donc pas adaptée en terme de performances. Nous allons voir ici quelques paramètres qui peuvent améliorer les performances de PostgreSQL. Vous pouvez utilisez le site [PgTune](http://pgtune.leopard.in.ua/) pour avoir une idée des paramètres à utiliser en fonction de vos ressources.
@ -307,7 +315,8 @@ La configuration par défaut est faite pour s'adapter à toutes sortes de machin
* Article intéressant : <https://pgdash.io/blog/scaling-postgres.html>
### Modifier un paramètre
## Modifier un paramètre
Pour changer la valeur d'une directive, il y a besoin de vérifier qu'[elle peut être modifiable à chaud](https://postgresqlco.nf/doc/fr/param/log_min_duration_statement/).
@ -323,7 +332,8 @@ Puis appliquer la nouvelle valeur:
UPDATE pg_settings SET setting = 5000 WHERE name = 'log_min_duration_statement';
~~~
## Administration
# Administration
Toutes les commandes d'administration doivent être exécutées depuis l'utilisateur Unix *postgres*.
@ -366,7 +376,6 @@ postgres=# GRANT SELECT ON ALL TABLES IN SCHEMA public TO <user>;
postgres=# ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO <user>;
~~~
* Suppression d'une base de données :
~~~
@ -514,7 +523,6 @@ On peux aussi le faire sur toutes les sequences d'une base avec un boucle en bas
postgres@:~$ for db in mabase ; do for seq in $(psql -qAt -c "SELECT relname FROM pg_class WHERE relkind = 'S';" $db) ; do psql -c "alter sequence \"$seq\" owner to $db" $db; done; done
~~~
* Terminer une session en cours (équivalent de KILL de MySQL) :
~~~
@ -564,7 +572,8 @@ où si on veux également listé les tables en incluant les schémas interne à
=# SELECT * FROM pg_stat_activity;
~~~
### Ajouter un langage
## Ajouter un langage
On peut installer un "langage" (PL/PGSL, PL/Perl, PL/TCP) pour une base. Exemple :
@ -589,15 +598,15 @@ postgres=# select * from pg_pltemplate;
~~~
## Sauvegardes et restaurations des données de PostgreSQL
# Sauvegardes et restaurations des données de PostgreSQL
Deux principales possibilités existent pour sauvegarder les bases de données PostgreSQL :
* sauvegarde SQL : simple à mettre en place, mais lent, impacte les requêtes en cours (locks) et consomme beaucoup de place ;
* sauvegarde du datadir : complètement transparent pour les connexions actives, synchro uniquement des fichiers modifiés par rapport à la dernière sauvegarde, mais plus complexe à mettre en place (gestion des WAL).
### Sauvegarde SQL
## Sauvegarde SQL
* Sauvegarde d'une seule base :
@ -642,7 +651,8 @@ $ pg_dump -F c <base> > dump.sql
$ pg_dumpall | gzip > dump.sql.gz
~~~
### Restauration SQL
## Restauration SQL
* Restauration de données au format SQL :
@ -664,7 +674,8 @@ Optimisations pour la restauration :
* augmenter autant que possible le `_maintenance_work_mem_` (attention, il sera multiplié par le nombre de processus utilisés pour la restauration). Dans tous les cas, ne pas dépasser les 2 Go. Peut être fait dans la conf ou dans une session ;
* Mettre la directive `synchronous_commit` à `off`.
### Sauvegarde du datadir
## Sauvegarde du datadir
Doc de référence : <http://www.postgresql.org/docs/9.6/static/continuous-archiving.html>
@ -691,7 +702,8 @@ postgres$ psql -c "SELECT pg_start_backup('evobackup')"
postgres$ psql -c "SELECT pg_stop_backup()"
~~~
#### Restauration du datadir
### Restauration du datadir
S'assurer que PostgreSQL est éteint, et restaurer le datadir :
@ -714,13 +726,14 @@ PostgreSQL va rejouer tous les WAL, exactement de la même manière qu'il le fai
Il est possible de rejouer les WAL jusqu'à une certaine date (`recovery_target_time`) ou un certain identifiant de transaction (`recovery_target_xid`).
## Mise à jour
# Mise à jour
La mise à jour de PostgreSQL d'une version majeure à une autre implique une mise à jour du datadir.
Dans Debian, chaque version de PostgreSQL a son propre paquet (*postgresql-9.3*, *postgresql-9.4*, etc…). La mise à jour doit donc forcément se faire de manière explicite par un `apt install` du paquet en question. Il n'est pas obligatoire de faire chaque mise à jour intermédiaire pour arriver à celle voulue (i.e. on peut passer de la 9.1 à la 9.6 sans devoir passer par la 9.2, 9.3, etc…).
### Procédure à suivre pour la mise à jour
## Procédure à suivre pour la mise à jour
Dans la procédure suivante, on suppose que l'on met à jour un cluster en version 9.3 vers la version 9.6. Le cluster s'appelle *main* (nom par défaut).
@ -760,9 +773,10 @@ psql (9.6.5)
# apt remove postgresql-9.3 postgresql-client-9.3 postgresql-contrib-9.3
~~~
## Monitoring
### Munin
# Monitoring
## Munin
On peut utiliser les plugins standards suivants :
@ -771,7 +785,8 @@ postgres_bgwriter postgres_connections_db postgres_xlog
postgres_checkpoints postgres_users
~~~
### Nagios
## Nagios
Vérification via le check *historique*:
@ -788,9 +803,9 @@ En Debian 10, on installe le paquet *check-pgactivity*
Ce check permet de monitorer différents point, comme les process *idle in transaction*, la réplication logique et streaming, etc...
## Plomberie
# Plomberie
### WAL
## WAL
* The Internals of PostgreSQL Chapter 9 WAL : <http://www.interdb.jp/pg/pgsql09.html>
* Article de Dalibo (ancien mais presque encore exact) : <https://www.dalibo.org/glmf108_postgresql_et_ses_journaux_de_transactions>
@ -843,7 +858,8 @@ Ce mécanisme de WAL est à la base de PostgreSQL, et il sert notamment pour la
Pour la sauvegarde on peut ainsi envoyer automatiquement un fichier de WAL dès qu'il est fermé avec l'option `archive_command = 'cp %p /tmp/pg_xlog_archives/%f'`.
### VACUUM et ANALYZE
## VACUUM et ANALYZE
`VACUUM` permet de nettoyer les données obsolètes (lignes d'une table qui ont été modifiées par un `UPDATE` par exemple) que PostgreSQL n'efface pas volontairement du disque puisque d'autres requêtes plus anciennes peuvent encore y accéder.
@ -861,7 +877,6 @@ Ces 2 opérations peuvent être exécutées en un seul coup :
=# VACUUM ANALYZE;
~~~
Par défaut, PostgreSQL lance au démarrage le processus `autovacuum launcher process` qui se charge d'exécuter des `VACUUM` et `ANALYZE` à intervalles réguliers. Les `VACUUM` et `ANALYZE` sont exécutés seulement si la quantité de données à nettoyer/réanalyser (en fait le nombre de `DELETE` et `UPDATE` que la table a reçu depuis son dernier passage) dépasse un certain seuil configurable.
`VACUUM` n'efface pas réellement les données sur le disque, il marque leurs emplacements comme libre de sorte que PostgreSQL puisse écrire dessus lorsqu'il aura à nouveau besoin d'écrire des données. Pour le forcer à libérer l'espace disque au niveau du système de fichiers, il faut exécuter un `VACUUM FULL`. Cette opération n'est pas faite par le démon `autovacuum` car elle requière de locker les tables en lecture et écriture (aucune requête n'est possible durant un `VACUUM FULL`). Le cas où l'on aurait besoin de lancer une telle opération serait après une grosse suppression de données (`DELETE`, `TRUNCATE`) et où on aurait besoin de récupérer de l'espace disque au niveau du système de fichiers pour autre chose. Dans les autres cas, il n'y a généralement pas d'utilité à lancer un `VACUUM FULL`.
@ -873,7 +888,7 @@ $ vacuumdb -a -f -v
~~~
## Benchmark
# Benchmark
`pgbench` est un outil intégré à PostgreSQL (dans Debian, il est dans le paquet `postgresql-contrib`), il permet de réaliser des tests, et d'avoir les résultats en transactions par secondes (tps). Plus d'inos sur la [doc officielle](https://www.postgresql.org/docs/9.6/static/pgbench.html).
Il est recommandé de réaliser 3 fois le bench pour avoir une meilleure précision.
@ -887,7 +902,7 @@ $ createdb -O postgres -E UNICODE pgbench
$ /usr/lib/postgresql/9.6/bin/pgbench -i pgbench -s 50
~~~
### Exemple avant optimisation
## Exemple avant optimisation
~~~
$ php -f script.php
@ -914,7 +929,7 @@ Testing: 10 clients with 50 transactions (5 samples)
pg_benchmark executed 30 tests in about 39 seconds
~~~
### Exemple après optimisation
## Exemple après optimisation
~~~
Shared Memory Max is 3,072.00Mb
@ -941,9 +956,9 @@ pg_benchmark executed 30 tests in about 5 seconds
~~~
## Outils
# Outils
### PgBouncer
## PgBouncer
[PgBouncer](https://pgbouncer.github.io/), de même que PgPool-II, permet de multiplexer plusieurs connexions à PostgreSQL en une seule : PgBouncer va recevoir les multiples connexions des clients et les envoyer à PostgreSQL à travers un pool de connexions qu'il maintient de manière persistente avec le serveur. L'intérêt principal est d'offrir un gain de performance puisque, avec PostgreSQL, une nouvelle connexion signifie un fork d'un nouveau processus, ce qui coûteux pour le système.
@ -1016,7 +1031,7 @@ pgbouncer=# show help;
Il existe un plugin Munin pour PgBouncer : <https://github.com/munin-monitoring/contrib/blob/master/plugins/postgresql/pgbouncer_>
### barman
## barman
* Documentation : <http://docs.pgbarman.org/release/2.4/>
@ -1089,7 +1104,7 @@ foo00 20180723T174316 - Mon Jul 23 21:47:34 2018 - Size: 413.2 GiB - WAL Size: 8
~~~
### pgbadger
## pgbadger
[PgBadger](https://github.com/dalibo/pgbadger) permet d'analyser des logs PostgreSQL et de générer une page HTML représentant les résultats sous forme de graphes et tableau de données.
@ -1132,7 +1147,7 @@ On peux mettre l'analyse des logs avec pgBadger dans la crontab comme ceci, avec
Vérifier aussi le logrotate des logs de posgresql, si on veux avoir un rapport journalier ou hebdomadaire.
### phpPgAdmin / pgAdmin III
## phpPgAdmin / pgAdmin III
phpPgAdmin et pgAdmin III sont des clients web (pour le premier) et lourd (pour le second) pour interagir avec des bases de données PostgreSQL.
@ -1144,7 +1159,7 @@ Installation :
~~~
### pg_stat_statements
## pg_stat_statements
`pg_stat_statements` est une extension PostgreSQL permettant de collecter des statistiques sur les requêtes reçues.
@ -1167,7 +1182,7 @@ bench=# SELECT query, calls, total_time, rows, 100.0 * shared_blks_hit / nullif(
~~~
## Activation du support des larges pages (Hugepages)
# Activation du support des larges pages (Hugepages)
Le support des Hugepages permet une optimisation de postgresql et du kernel, pour les requêtes avec un besoin important de mémoire.
@ -1283,11 +1298,11 @@ Et enfin, on active la variable huge_page dans `/etc/postgresql/9.6/main/postgre
huge_pages = on
~~~
## Réplication
# Réplication
Plusieurs solutions de réplication plus ou moins avancées existent avec PostgreSQL :
* _Streaming Replication_ ou _Physique_ : les données sont transférées immédiatement par un processus dédié (_walsender_) dans une connexion réseau établie avec le réplica. Contrairement aux autres solutions, cela nécessite une légère charge supplémentaire par réplica sur le maître pour faire tourner le processus _walsender_. En général ce système est couplé à l'envoi des *WAL* car si le réplica est trop en retard par rapport au master, il va lire les *WAL* jusqu'à avoir rattrapé son retard puis basculera tout seul sur la *streaming replication*
* _Logique_ : les données sont répliquées au niveau des objets par un système de publication/abonnement
* _PITR_, _Point In Time Recovery_ : copie des logs de transaction (_WAL_) sur un serveur distant pour archivage. Ils peuvent ensuite être rejoués jusqu'à un point précis en cas de perte de données par exemple.
@ -1300,29 +1315,34 @@ Pour plus de détails sur ces solutions, voir ce post sur [dba.stackexange.com](
> *Note* : l'expédition des logs entre des serveurs pgsql nécessite qu'ils soient à la même version majeure.
### Streaming Réplication
## Streaming Réplication
Voir [/HowtoPostgreSQL/ReplicationPhysique]().
### Réplication Logique
## Réplication Logique
Voir [/HowtoPostgreSQL/ReplicationLogique]().
### Slony
## Slony
Voir [/HowtoPostgreSQL/Slony]().
## Utilisation
# Utilisation
Voir [/HowtoPostgreSQL/Utilisation]().
## FAQ
### J'ai lancé `pg_top` mais je n'ai aucun résultat
# FAQ
## J'ai lancé `pg_top` mais je n'ai aucun résultat
Vous utilisez une version non compatible avec votre base, essayez avec une version du paquet `ptop`.
### Rendre PostgreSQL moins susceptible d'être killer par l'OMkiller
## Rendre PostgreSQL moins susceptible d'être killer par l'OMkiller
Voici une unité systemd avec des ajustements sur les variables d'environnement pour rendre PostgreSQL moins killable par l'OMkiller
@ -1348,7 +1368,8 @@ RemainAfterExit=on
WantedBy=multi-user.target
~~~
### Activer module `pgcrypto`
## Activer module `pgcrypto`
Dans le *shell* `psql` :
@ -1372,7 +1393,8 @@ hostname=# select pg_get_functiondef(to_regproc('gen_random_uuid'));
(1 row)
~~~
### Activer module `postgis`
## Activer module `postgis`
Il faut en premier installé les paquets suivants, exemple sur une instance postgresql 11 :
@ -1400,7 +1422,8 @@ Activé topology :
foo=# CREATE EXTENSION IF NOT EXISTS postgis_topology;
~~~
### Commande COPY
## Commande COPY
<https://docs.postgresql.fr/current/sql-copy.html>