From 918c836508fe66aa5c09b093ee7d903192eb9466 Mon Sep 17 00:00:00 2001 From: whirigoyen Date: Mon, 28 Feb 2022 15:16:31 +0100 Subject: [PATCH] =?UTF-8?q?Descente=20d'un=20#=20dans=20la=20hi=C3=A9rarch?= =?UTF-8?q?ie=20du=20sommaire?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- HowtoPostgreSQL.md | 133 ++++++++++++++++++++++++++------------------- 1 file changed, 78 insertions(+), 55 deletions(-) diff --git a/HowtoPostgreSQL.md b/HowtoPostgreSQL.md index c6165252..b9852cd2 100644 --- a/HowtoPostgreSQL.md +++ b/HowtoPostgreSQL.md @@ -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!=''; ~~~ -### 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 d’exé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 : -### 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 ; postgres=# ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO ; ~~~ - * 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 > 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 : @@ -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 : * Article de Dalibo (ancien mais presque encore exact) : @@ -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 : -### barman +## barman * Documentation : @@ -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