Suite à l'installation, une première instance *main* est créée avec les paramètres par défaut.
### Dépôt PGDG
Le *PostgreSQL Global Development Group (PGDG)* maintient un dépôt Debian qui contient plusieurs versions majeures de PostgreSQL (plus récentes et plus anciennes) que celle disponible dans Debian stable, ainsi que plusieurs extensions au serveur.
Ajouter le dépôt un fichier sources.list `/etc/apt/sources.list.d/jessie-pgdg.list` :
Une surcouche Debian permet de gérer très simplement plusieurs versions et plusieurs instances d'une même version de PostgreSQL. Cela permet entre autre de faciliter les migrations d'un version majeure à une autre.
Par défaut le script d'init contrôle tous les instances actives. Pour contrôler seulement une instances en particulier:
Le port d'écoute de postgres sera automatiquement incrémenté de 1 pour ne pas rentrer en conflit avec les autres instances. L'encodage utilisé par défaut pour l'instance est celui du système. Si le système est en en_US.UTF-8 par défaut, l'instance créée sera en en_US.UTF-8.
On peut remarquer que toute l'arborescence est organisée en fonction des versions et des instances. Cela permet de les rendre réellement indépendantes :
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:
~~~
# sudo -u postgres psql
psql (9.6.0, server 9.4.9)
Type "help" for help.
postgres=#
~~~
À noter que l'utilisateur Unix *postgres* a tous les droits sur les fichiers de configuration, les journaux, etc… sur le système.
Par défaut, un utilisateur Unix *foo* sera automatiquement lié à son compte PostgreSQL *foo* si il existe. C'est très pratique dans le cas de multiples comptes web sur la machine, on évite ainsi de stocker un mot de passe dans un fichier de paramètre de connexion.
La gestion des permissions se fait dans le fichier de configuration `pg_hba.conf` de l'instance en question.
Si on préfère passer par un mot de passe pour s'authentifier, il faut changer la ligne suivante dans le fichier `pg_hba.conf` :
Comme pour les instances, par défaut la base sera créé avec l'encodage du système. Si le système est en UTF-8 par défaut, la base créée sera en UTF-8. On peut spécifier un encodage alternatif avec l'option `-E`.
* 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).
*Attention:* ne sauvegarde ni les tablespaces, ni les roles.
Pour sauvegarder ces derniers:
~~~
$ pg_dumpall -g >dump.sql
~~~
Sauvegarde de toutes les bases:
~~~
$ pg_dumpall >dump.sql
~~~
Sauvegarde d'une table d'une base de données:
~~~
$ pg_dump -t <table><base>
~~~
À moins de vouloir restaurer le contenu sur un autre moteur de base de données, il est préférable de faire des dumps au format _custom_, qui permet la compression, un processus de restauration sur plusieurs threads, et de sélectionner finement quels éléments restaurer lors de la restauration:
~~~
$ pg_dumpall -F c >all.dump
~~~
#### Restauration SQL
Restauration de données au format SQL:
~~~
$ psql <base><dump.sql
~~~
Restauration de données au format _custom_:
~~~
$ pg_restore -F c all.dump
~~~
*Important:* il est nécessaire de faire un `ANALYSE` après une restauration de tables ou bases de données afin de mettre à jour les statistiques de PostgreSQL. Ces statistiques sont utilisées par PostgreSQL pour déterminer la manière la plus optimum de requêter la base en fonction de la répartition des valeurs des champs.
* 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 2Go. Peut être fait dans la conf ou dans une session;
* Mettre la directive `synchronous_commit` à `off`.
Ainsi, dès qu'un WAL est marqué comme complété (`pg_xlog/archive_status/*.ready`), il est copié sur le serveur de backup conformément à `archive_command`. Si la copie à réussi, le `.ready` est renommé en `.done`.
Attention à ne surtout pas effacer le contenu de `pg_xlog/`, qui peut contenir le dernier WAL courant (donc pas encore copié sur le serveur de backup).
PostgreSQL va rejouer tous les WAL, exactement de la même manière qu'il le fait en cas de crash, puis se mettra à accepter les connexions.
Il est possible de rejouer les WAL jusqu'à une certaine date (`recovery_target_time`) ou un certain identifiant de transaction (`recovery_target_xid`).
### Langage
On peut installer un "langage" (PL/PGSL, PL/Perl, PL/TCP) pour une base. Exemple :
Faire un VACUUM FULL sur toutes les bases de données :
~~~
$ vacuumdb -a -f -v
~~~
ANALYSE sur toutes les tables d'une base de données :
~~~
$ psql mydb
=# ANALYZE;
~~~
## Optimisation
La configuration par défaut est fait pour s'adapter à toutes sortes de machines, elle n'est donc pas adapté en terme de performances. Nous allons voir ici quelques paramètres qui peuvent améliorer les performances de PostgreSQL.
* shared_buffers : Ce paramètre détermine la quantité de mémoire dédié à PostgreSQL pour mettre en cache les données. *Il est recommandé de mettre 1/4 de la quantité de RAM total de votre machine.*[[BR]]
*/!\ Attention il est nécessaire de ne pas dépasser la valeur de la mémoire partagé du kernel, pour la changer, ajoutez kernel.shmmax = VALEUR en octets dans le sysctl.*[[BR]]
* max_connections : Détermine le nombre maximum de clients connectés simultanément. Ce paramètre est très important pour certains paramètres car les ressources mémoires qui sont ou seront allouées par client, il est donc suggérer d'utiliser le maximum de mémoire possible. *work_mem*nb_clients=maxRAM.*
* effective_cache_size : Ce paramètre détermine combien de mémoire devrait être disponible pour l'OS et les mémoire tampons de PostgreSQL, ce n'est pas une allocation. Cette valeur est seulement utilisé par le planificateur de requêtes de PostgreSQL pour savoir si les requêtes vont tenir en RAM ou pas. *Il est recommandé de mettre 50% de la RAM voir 75%.*
* checkpoint_segments : PostgreSQL écrit les transactions effectuées dans un fichier de log (nommé _WAL_, pour _Write Ahead Log_). Un segment est en fait un fichier, qui fait 16Mo par défaut. Un checkpoint est fait à chaque _checkpoint_segment_, par défaut 3, donc 3*16 = 48Mo, ce qui peut être un goulot d'étranglement de faire des checkpoints tout les 48Mo. *Il est recommandé de le mettre entre 8 (faible écritures sur les bases) et 64 (beaucoup d'écritures). 16 est une bonne valeur pour un usage standard.*
* checkpoint_completion_target : À partir de PostgreSQL 8.3, les checkpoint sont écrits pendant que le système commence à travailler sur le prochain checkpoint. Par défaut la valeur est de 0.5 (50%), et donc PostgreSQL s'occupe de finir le checkpoint quand le suivant est fini à 50%. *Il est recommandé de fixer 90%.*
* autovacuum : PostgreSQL réalise de nombreuses maintenance pour nettoyer la base de données. C'est une mauvaise idée de le de désactiver complètement, mais cela peut-être utile de le désactiver temporairement, notamment en cas de forte charge.
* max_fsm_pages et max_fsm_relations : */!\ Plus utilisé dans PostgreSQL >=8.4.* Les paramètres sont maintenant dynamique, [plus d'infos](http://www.depesz.com/index.php/2008/10/04/waiting-for-84-new-fsm-free-space-map/).
* work_mem : Le work_mem permet d'éviter lors de grosses opérations, de swapper les données sur le disque pour les traiter. *Attention il est rattaché au nombres de clients ! Par exemple un work_mem de 50Mo avec 30 utilisateurs, cela donne 1.5Go, il est donc facile de faire passer la machine en out-of-memory…*[[BR]]
* wal_buffers : La valeur par défaut est bien trop petite (64Ko), *il est recommandé de la passer de 1Mo à 16Mo.*
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).
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
* _PITR_, _Point In Time Recovery_: copie des logs de transaction (_WAL_) sur un serveur distant pour archivage. Ils peuvent ensuite être rejoué jusqu'à un point précis en cas de perte de donnée par exemple.
* _Warm Standby_: les _WAL_ sont copiés sur un second serveur sur lequel tourne un PostgreSQL en mode _recovery_ constant. Chaque segment reçu est rejoué par PostgreSQL. Il est alors prêt à prendre le relais en cas de panne sur le serveur maître.
* _Hot Standby_: le principe est le même que pour le _Warm Standby_, mais le serveur esclave peut être interrogé en lecture.
* _Streaming Replication_: ce ne sont plus les logs qui sont envoyés (qui nécessite un certain temps de propagation, car le fichier est transféré une fois plein), mais les données sont transféré immédiatement par un processus dédié (_walsender_) dans une connexion réseau établie avec le serveur esclave. Contrairement aux autres solutions, cela nécessite une légère charge supplémentaire par esclave sur le maître pour faire tourner le processus _walsender_.