relecture / amélioration

This commit is contained in:
Gregory Colpart 2018-01-26 15:47:54 +01:00
parent 230e301dd6
commit e9015d3d52
3 changed files with 52 additions and 246 deletions

View file

@ -636,216 +636,27 @@ psql (9.6.5)
# apt remove postgresql-9.3 postgresql-client-9.3 postgresql-contrib-9.3
~~~
## Utilisation
### Connexion
On peut maintenant "utiliser" notre base de données avec le client en ligne PostgreSQL en ligne de commande :
~~~
$ psql base login
ma_base=>
~~~
Voici quelques commandes de base :
~~~
\l = liste des bases
\d = liste des tables
\q = quitter
\h = aide
SELECT version(); = version PostgreSQL
SELECT current_date; = date actuelle
\i fichier.sql = lit les instructions du fichier fichier.sql
\d table = décrit une table (comme DESCRIBE avec MySQL)
~~~
Pour changer de base de données :
~~~
=> \c base;
~~~
### Création de table
Voici les différents types de données pour les champs d'une table :
~~~
char(n)
varchar(n)
int
real
double precision
date
time
timestamp
interval
~~~
Remarque : on peut aussi définir ses propres types de données
La syntaxe classique pour créer/supprimer une table :
~~~
=> CREATE TABLE ma_table (col1 type, […], coln type);
=> DROP TABLE ma_table;
~~~
Pour la forme un petit exemple tiré de la doc de PostgreSQL :
~~~
=> CREATE TABLE weather (
city varchar(80),
temp_lo int, -- low temperature
temp_hi int, -- high temperature
prcp real, -- precipitation
date date
);
~~~
Note : deux tirets `--` introduisent des commentaires.
Pour mettre à jour des tables :
~~~
=> ALTER TABLE evosondage_admin ADD cycle varchar(25);
=> ALTER TABLE evosondage_admin ALTER column cycle SET not null;
=> ALTER TABLE evosondage_admin DROP column annee;
~~~
### Insertion de données
Insertion de tous les champs d'une table :
~~~
=> INSERT INTO weather VALUES ('San Francisco', 46, 50, 0.25, '1994-11-27');
~~~
Insertion en précisant les champs :
~~~
=> INSERT INTO weather (city, temp_lo, temp_hi, prcp, date)
VALUES ('San Francisco', 43, 57, 0.0, '1994-11-29');
~~~
Insertion à partir d'un fichier externe :
~~~
=> COPY weather FROM '/home/user/weather.txt';
~~~
Note : voir http://www.postgresql.org/docs/current/interactive/sql-copy.html
### Gestion des indexes
~~~
=> CREATE INDEX mytable_idx1 ON mytable(col1);
=> REINDEX TABLE mytable;
=> DROP INDEX mytable_idx1;
~~~
Pour réindexer une base de données complète :
~~~
$ psql mydb
=> REINDEX DATABASE mydb;
~~~
### Extraction de données
Rien ne vaut des exemples :
~~~
=> SELECT * FROM weather;
=> SELECT city, (temp_hi+temp_lo)/2 AS temp_avg, date FROM weather;
=> SELECT * FROM weatherWHERE city = 'San Francisco' AND prcp > 0.0;
=> SELECT DISTINCT city FROM weather ORDER BY city;
~~~
Avec des jointures :
~~~
=> SELECT * FROM weather, cities WHERE city = name;
=> SELECT weather.city, weather.temp_lo, cities.location FROM weather, cities WHERE cities.name = weather.city;
=> SELECT * FROM weather INNER JOIN cities ON (weather.city = cities.name);
=> SELECT * FROM weather LEFT OUTER JOIN cities ON (weather.city = cities.name);
=> SELECT * FROM weather w, cities c WHERE w.city = c.name;
~~~
Avec des fonctions (Aggregate Functions) :
~~~
=> SELECT max(temp_lo) FROM weather;
~~~
Attention, les "Aggregate Functions" ne peuvent être utilisées dans la clause WHERE.
Ainsi la requête suivante est fausse :
~~~
=> SELECT city FROM weather WHERE temp_lo = max(temp_lo);
~~~
On devra donc faire :
~~~
=> SELECT city FROM weather WHERE temp_lo = (SELECT max(temp_lo) FROM weather);
~~~
On pourra bien sûr utilise _GROUP BY…_, _HAVING…_, etc.
Pour envoyer le résultat dans un fichier :
~~~
=> SELECT * FROM weather WHERE temp_lo=10 \g '/tmp/output'
~~~
### Mise à jour des données
Toujours avec un exemple :
~~~
=> UPDATE weather SET temp_hi = temp_hi - 2, temp_lo = temp_lo - 2 WHERE date > '1994-11-28';
~~~
### Suppression des données
Encore avec un exemple :
~~~
=> DELETE FROM weather WHERE city = 'Hayward';
~~~
Pour effacer toutes les données d'une table :
~~~
=> DELETE FROM weather;
~~~
### Schémas
Par défaut, PostgreSQL utilise le schéma *public* mais il est possible d'utiliser d'autres schémas.
* Créer un nouveau schéma :
~~~
=> CREATE SCHEMA foo;
~~~
* Lister les schémas d'une base :
~~~
=> \dn
~~~
* Lister les tables/indexes dans un schéma :
~~~
=> \dt foo.
=> \di foo.
~~~
## Monitoring
### Munin
On peut utiliser les plugins standards suivants :
~~~
postgres_bgwriter postgres_connections_db postgres_xlog
postgres_checkpoints postgres_users
~~~
### Nagios
Vérification via :
~~~
/usr/lib/nagios/plugins/check_pgsql -H localhost -l nagios -p PASSWORD
OK - database template1 (0.011915 sec.)|time=0.011915s;2.000000;8.000000;0.000000
~~~
## VACUUM et ANALYZE
@ -878,16 +689,16 @@ $ vacuumdb -a -f -v
## Benchmark
pgbench est un outil intégré à PostgreSQL (dans debian, il est dans le paquet, postgresql-contrib - /usr/lib/postgresql/8.4/bin/pgbench), 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](http://docs.postgresqlfr.org/8.3/pgbench.html).
`pgbench` est un outil intégré à PostgreSQL (dans Debian, il est dans le paquet `postgresql-contrib` - /usr/lib/postgresql/8.6/bin/pgbench), 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.
[Un petit script php](http://edoceo.com/creo/pg-bench-suite) permet d'automatiser les benchs
[Un petit script PHP](http://edoceo.com/creo/pg-bench-suite) permet d'automatiser les benchs.
~~~
# aptitude install php5-cli postgresql-contrib
# apt install php7.0-cli postgresql-contrib
$ wget http://pastebin.com/download.php?i=hD570TgL -O /tmp/script.php
$ su postgres
$ createdb -O postgres -E UNICODE pgbench
$ /usr/lib/postgresql/8.4/bin/pgbench -i pgbench -s 50
$ /usr/lib/postgresql/8.6/bin/pgbench -i pgbench -s 50
~~~
### Exemple avant optimisation
@ -966,9 +777,9 @@ Augmentation du nombre de fichiers ouverts maximum :
# echo "ulimit -n 65536" >>/etc/default/pgbouncer
~~~
Note : en stretch PgBouncer n'a toujours pas d'unité systemd donc le fichier `/etc/default/pgbouncer` est toujours pris en compte.
> *Note* : en Stretch PgBouncer n'a toujours pas d'unité systemd donc le fichier `/etc/default/pgbouncer` est toujours pris en compte.
La configuration se fait ensuite dans le fichier `/etc/pgbouncer/pgbouncer.ini
La configuration se fait ensuite dans le fichier `/etc/pgbouncer/pgbouncer.ini` :
~~~
[databases]
@ -1007,7 +818,7 @@ Il est également nécessaire de lister les utilisateurs pouvant se connecter, p
[…]
~~~
Une fois démarré, PgBouncer écoute sur le port tcp/6432.
Une fois démarré, PgBouncer écoute sur le port TCP/6432.
Une pseudo-base spécifique à PgBouncer permet de faire des opérations d'administration et de récupérer des statistiques intéressantes :
@ -1016,39 +827,36 @@ psql -p 6432 -U pgbpostgres pgbouncer
pgbouncer=# show help;
~~~
### pgpool -> rmw
(TODO)
### barman
(TODO)
[barman](http://www.pgbarman.org/) est un outil pour gérer les sauvegardes et les restaurations
~~~
# apt install barman barman-cli
~~~
Voir [la documentation Barman](http://docs.pgbarman.org/release/2.3/).
### pgbadger
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.
[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.
(TODO)
~~~
# apt install pgbadger
~~~
### phpPgAdmin / pgAdmin III
phpPgAdmin et pgAdmin III sont des clients web (pour le premier) et lourd (pour le second) pour interragir avec des bases de données PostgreSQL.
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.
Installation :
~~~
# apt install phppgadmin
~~~
~~~
# apt install pgadmin3
~~~
(TODO)
### pg_bench_*
(TODO)
## Réplication
@ -1059,7 +867,7 @@ Plusieurs solutions de réplication plus ou moins avancées existent avec Postgr
* _Hot Standby_ : le principe est le même que pour le _Warm Standby_, mais le réplicat peut être interrogé en lecture. Il y a néanmois une légère différence perpétuelle entre le master et le réplicat car le *WAL* est transféré seulement lorsque l'archive a fini d'être écrite.
* _Streaming Replication_ : les données sont transférées immédiatement par un processus dédié (_walsender_) dans une connexion réseau établie avec le réplicat. Contrairement aux autres solutions, cela nécessite une légère charge supplémentaire par réplicat 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éplicat 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*
Pour plus de détails sur ces solutions, voir ce post sur [dba.stackexange.com](https://dba.stackexchange.com/questions/73812/postgresql-streaming-versus-file-based-replication-in-terms-of-server-behavior). Pour d'autres types de solutions pour avoir de la haute disoponibilite, postgresql a [une page sur cela dans leur documentation](https://www.postgresql.org/docs/current/static/different-replication-solutions.html).
Pour plus de détails sur ces solutions, voir ce post sur [dba.stackexange.com](https://dba.stackexchange.com/questions/73812/postgresql-streaming-versus-file-based-replication-in-terms-of-server-behavior). Pour d'autres types de solutions pour avoir de la haute disoponibilite, PostgreSQL a [une page sur cela dans leur documentation](https://www.postgresql.org/docs/current/static/different-replication-solutions.html).
> *Note* : l'expédition des logs entre des serveurs pgsql nécessite qu'ils soient à la même version majeure.
@ -1072,11 +880,14 @@ Voir [/HowtoPostgreSQL/Replication]().
Voir [/HowtoPostgreSQL/Slony]().
## Utilisation
Voir [/HowtoPostgreSQL/Utilisation]().
## FAQ
pg_top ne montre rien ?
essayer une autre version du paquet ptop
### 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`.

View file

@ -16,8 +16,8 @@ Par rapport au mode de réplication _Hot Standby_, l'avantage avec la réplicati
Pré-requis pour pouvoir mettre en place une infra avec 1 maître et 1 réplicat :
* même architecture (32 bits/64 bits) sur les 2 serveur ;
* même version majeure de PostgreSQL sur les 2 serveur (et même version mineure est conseillé) ;
* même architecture (32 bits/64 bits) sur les 2 serveurs ;
* même version majeure de PostgreSQL sur les 2 serveurs (et même version mineure est conseillé) ;
## Installation de PostgreSQL

View file

@ -1,11 +1,6 @@
**Cette page a été importée automatiquement de notre ancien wiki mais n'a pas encore été révisée.**
## Réplication PostgreSQL avec Slony
Documentations de référence :
* <http://slony.info/documentation/2.0/tutorial.html>
* /usr/share/doc/slony1-2-bin/README.Debian.gz
Documentations : <http://slony.info/documentation/2.0/tutorial.html>
### Limitations
@ -26,7 +21,7 @@ Slony (_éléphants_ en russe, en rapport avec le logo de PostgreSQL entre autre
### Installation
~~~
# aptitude install postgresql-8.4 postgresql-8.4-slony1-2 slony1-2-bin
# apt install postgresql-9.6 postgresql-9.6-slony1-2 slony1-2-bin
~~~
### Préparation PostgreSQL
@ -190,14 +185,14 @@ if ($ENV{"SLONYNODES"}) {
dbname => 'dbrepl',
port => 5432,
user => 'slony',
password => 'slonypass');
password => 'PASSWORD');
add_node(node => 2,
host => 'test2',
dbname => 'dbrepl',
port => 5432,
user => 'slony',
password => 'slonypass');
password => 'PASSWORD');
}
# The $SLONY_SETS variable contains information about all of the sets