Avant de faire quoi que ce soit, vous devez initialiser un emplacement de
stockage pour la base de données. Nous appelons ceci un groupe de
bases de données (le standard SQL utilise le
terme de groupe de catalogues). Un groupe de bases de données est une
collection de bases données et est géré par une seule instance d'un serveur
de bases de données en cours d'exécution. Après initialisation, un groupe de
bases de données contiendra une base de données nommée
postgres, qui a pour but d'être la base de données par
défaut utilisée par les outils, les utilisateurs et les applications tiers.
Le serveur de la base de données lui-même ne requiert pas la présence de la
base de données postgres mais beaucoup d'outils supposent
son existence. Il existe deux bases de données supplémentaires créées dans
chaque instance lors de l'initialisation. Elles ont pour nom
template1 et template0. Comme leur nom
le suggère, elles seront utilisées comme modèle pour les bases de données
créées après ; elles ne devraient pas être utilisées pour un vrai
travail (voir le Chapitre 22 pour des informations
sur la création de nouvelles bases de données dans l'instance).
En terme de système de fichiers, un groupe de bases de données est un
simple répertoire sous lequel les données seront stockées. Nous l'appelons
le répertoire de données ou l'emplacement
des données. Le choix de cet emplacement vous appartient
complètement. Il n'existe pas de valeur par défaut bien que les
emplacements tels que /usr/local/pgsql/data ou
/var/lib/pgsql/data sont populaires. Le répertoire de
données doit être initialisé avant d'être utilisé, en utilisant le
programme initdb qui
est installé avec PostgreSQL.
Si vous utilisez une version pré-packagée de
PostgreSQL, il pourrait bien avoir une
convention spécifique pour l'emplacement du répertoire de données, et il
pourrait aussi fournir un script pour créer le répertoire de données. Dans
ce cas, il est conseillé d'utiliser ce script plutôt que d'exécuter
directement initdb. Consultez la documentation du paquet
pour les détails.
Pour initialiser un groupe de bases de données, exécutez la commande
initdb et indiquez l'emplacement désiré sur le système
de fichiers de l'instance avec l'option -D, par exemple
$initdb -D /usr/local/pgsql/data
Notez que vous devez exécuter cette commande en étant connecté sous le compte de l'utilisateur PostgreSQL décrit dans la section précédente.
Autrement, vous pouvez exécuter initdb via le programme
pg_ctl
ainsi :
$pg_ctl -D /usr/local/pgsql/data initdb
C'est peut-être plus intuitif si vous utilisez déjà
pg_ctl pour démarrer et arrêter le serveur (voir Section 18.3 pour les détails). Un gros intérêt est de ne
connaître que cette seule commande pour gérer l'instance du serveur de
bases de données.
initdb tentera de créer le répertoire que vous avez
spécifié si celui-ci n'existe pas déjà. Bien sûr, cela peut échouer si
initdb n'a pas les droits pour écrire dans le répertoire
parent. Il est généralement recommandé que l'utilisateur
PostgreSQL soit propriétaire du répertoire des
données, mais aussi du répertoire parent pour que ce problème ne se
présente pas. Si le répertoire parent souhaité n'existe pas non plus, vous
aurez besoin de le créer, en utilisant les droits de l'utilisateur root si
nécessaire. Le processus pourrait ressembler à ceci :
root#mkdir /usr/local/pgsqlroot#chown postgres /usr/local/pgsql
initdb refusera de s'exécuter si le répertoire des données
existe et contient déjà des fichiers. Cela permet de prévenir tout écrasement
accidentel d'une installation existante.
Comme le répertoire des données contient toutes les données stockées
dans la base, il est essentiel qu'il soit protégé contre les
accès non autorisés. En conséquence, initdb
supprime les droits d'accès à tout le monde sauf à l'utilisateur
PostgreSQL, et optionnellement au groupe.
L'accès au groupe, s'il est autorisé, est en lecture seule.
Cela permet à un utilisateur non privilégié, du même groupe que le
propriétaire de l'instance, de faire une sauvegarde des fichiers ou d'effectuer
des opérations qui ne requièrent qu'un accès en lecture.
Notez qu'activer ou désactiver l'accès au groupe sur une instance
préexistante exige qu'elle soit arrêtée et que les droits soient mis en place
sur tous les répertoires et fichiers avant de redémarrer PostgreSQL.
Sinon, un mélange des droits pourrait exister dans le répertoire de données.
Pour les instances qui ne donnent accès qu'au propriétaire, les droits
appropriés sont 0700 sur les répertoires et
0600 sur les fichiers. Pour les instances qui permettent
aussi la lecture par le groupe, les droits appropriés sont
0750 sur les répertoires et 0640
sur les fichiers.
Néanmoins, bien que le contenu du répertoire soit sécurisé, la configuration
d'authentification du client par défaut permet à tout utilisateur local de se
connecter à la base de données et même à devenir le superutilisateur de
la base de données. Si vous ne faites pas confiance aux utilisateurs
locaux, nous vous recommandons d'utiliser une des options -w ou
--pwprompt de la commande initdb pour
affecter un mot de passe au superutilisateur de la base de
données . De plus, spécifiez -A scram-sha-256
de façon à ce que la méthode d'authentification
trust par défaut ne soit pas utilisée ; ou modifiez le fichier
pg_hba.conf généré après l'exécution
d'initdb (d'autres
approches raisonnables incluent l'utilisation de l'authentification
peer ou les droits du système de fichiers pour
restreindre les connexions. Voir le Chapitre 20 pour plus d'informations).
initdb initialise aussi la
locale par défaut du groupe de bases de
données. Normalement, elle prends seulement le paramétrage local dans
l'environnement et l'applique à la base de données initialisée. Il est
possible de spécifier une locale différente pour la base de données ;
la Section 23.1 propose plus d'informations là-dessus.
L'ordre de tri utilisé par défaut pour ce cluster de bases de données est
initialisé par initdb et, bien que vous pouvez créer de
nouvelles bases de données en utilisant des ordres de tris différents, l'ordre
utilisé dans les bases de données modèle que initdb a créé ne peut pas être
modifié sans les supprimer et les re-créer. Cela a aussi un impact sur les
performances pour l'utilisation de locales autres que c
ou posix. Du coup, il est important de faire ce choix
correctement la première fois.
initdb configure aussi le codage par défaut de l'ensemble
de caractères pour le groupe de bases de données. Normalement, cela doit
être choisi pour correspondre au paramétrage de la locale. Pour les détails,
voir la Section 23.3.
Les locales différentes de C et POSIX
se basent sur la bibliothèque de collationnement du système pour le tri
dépendant du jeu de caractères. Cela contrôle l'ordre des clés stockées
dans les index. Pour cette raison, une instance ne peut pas basculer vers
une version incompatible de la bibliothèque de collationnement, que ce soit
pour une restauration d'une sauvegarde PITR mais aussi pour de la
réplication binaire en flux ou pour un système d'exploitation différent, ou
une mise à jour du système d'exploitation.
Beaucoup d'installations créent leur instance dans des systèmes de fichiers (volumes) autres que le volume racine de la machine. Si c'est votre choix, il est déconseillé d'utiliser le répertoire principal de ce volume secondaire (son point de montage) comme répertoire de données. Une meilleure pratique est de créer un répertoire au sein du point de montage, répertoire possédé par l'utilisateur PostgreSQL, puis de créer le répertoire de données à l'intérieur. Ceci évite des problèmes de droits, tout particulièrement lors d'opérations comme pg_upgrade, et garantit aussi des échecs propres si le volume secondaire n'est pas disponible.
De manière générale, tout système de fichiers avec une sémantique POSIX est utilisable avec PostgreSQL. Les utilisateurs peuvent en choisir de différents pour diverses raisons, comme le support du fournisseur, la performance ou la familiarité. L'expérience montre que, toutes choses égales par ailleurs, on ne doit pas espérer de grosses différences de performances ou de comportement en changeant juste de système de fichiers ni en faisant de petites modifications de sa configuration.
Il est possible d'utiliser un système de fichier NFS pour le répertoire des données de PostgreSQL. PostgreSQL ne fait rien de spécial sur un un système de fichier NFS, c'est-à-dire qu'il suppose un comportement identique à celui de disques connectés locaux. PostgreSQL n'utilise aucune fonctionnalité connue pour un comportement non standard sur NFS, comme le verrouillage de fichier.
Le seul pré-requis ferme pour l'utilisation de NFS
avec PostgreSQL est que celui-ci soit
monté avec l'option hard. Avec cette option,
des processus peuvent rester « pendants » indéfiniment
s'il y a des problèmes réseau ;cette configuration nécessite donc
une mise en place soigneuse.
L'option soft interrompra les appels système
en cas de problème réseau, mais PostgreSQL
ne répétera pas ces appels interrompus ; une telle interruption
mènera donc à la levée d'une erreur d'entrée-sortie.
Il n'est pas nécessaire d'utiliser l'option de montage sync.
Le comportement de async est suffisant car
PostgreSQL génère des appels fsync
quand c'est approprié pour purger les caches en écriture.
(C'est analogue au fonctionnement sur un système de fichiers local).
Cependant, il est fortement conseillé d'utiliser l'option
sync pour l'export depuis le
serveur NFS sur les systèmes où elle existe
(principalement Linux).
Sinon, il n'y a pas de garantie qu'un fsync,
ou son équivalent, sur le client NFS, atteigne le stockage permanent du
serveur, ce qui causerait une corruption, comme si on tournait avec
fsync à off.
Les valeurs par défaut des options de montage et d'export diffèrent selon
les fournisseurs et les versions ; il est donc recommandé de les
vérifier, voire de les préciser explicitement pour lever toute
ambiguïté.
Dans certains cas, un stockage externe peut être utilisé soit par NFS, soit par un protocole de plus bas niveau comme iSCSI. Dans ce dernier cas, le stockage apparaît comme un périphérique par bloc et n'importe quel système de fichiers peut y être créé. Cette approche peut éviter au DBA de gérer les particularités du NFS, mais la complexité de la gestion du stockage distant est bien sûr repoussée à un autre niveau.