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. Une autre base de données est créée à l'intérieur
de chaque groupe lors de l'initialisation. Elle est appelée
template1
. Comme le nom le suggère, elle sera utilisée
comme modèle pour les bases de données créées après ; elle ne devrait
pas être utilisée pour un vrai travail (voir le Chapitre 22 pour des informations sur la création de
nouvelles bases de données dans le groupe).
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. Pour initialiser un
groupe de bases de données, utilisez la commande initdb, installée avec
PostgreSQL. L'emplacement désiré sur le groupe de
fichier est indiqué par 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 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/pgsql
root#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 par
le système de bases de données, il est essentiel qu'il soit sécurisé par
rapport à des accès non autorisés. Du coup, initdb
supprimera les droits d'accès à tout le monde sauf l'utilisateur
PostgreSQL.
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 super-utilisateur 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 super-utilisateur de la base de
données . De plus, spécifiez -a md5
ou
-a mot_de_passe
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 sur des systèmes de fichiers (volumes) autres que le volume racine de la machine. Si vous choisissez de le faire, il n'est pas conseiller d'essayer d'utiliser le répertoire principal du volume secondaire (le point de montage) comme répertoire des données. Une meilleure pratique est de créer un répertoire dans le répertoire du point de montage dont l'utilisateur PostgreSQL est propriétaire, puis de créer le répertoire de données à l'intérieur. Ceci évite des problèmes de droits, tout particulièrement pour des opérations telles que pg_upgrade, et cela vous assure aussi d'échecs propres si le volume secondaire n'est pas disponible.
Beaucoup d'installations créent les clusters de bases de données sur des systèmes de fichiers réseau. Parfois, cela utilise directement par NFS. Cela peut aussi passer par un NAS (acronyme de Network Attached Storage), périphérique qui utilise NFS en interne. PostgreSQL ne fait rien de particulier avec les systèmes de fichiers NFS, ceci signifiant que PostgreSQL suppose que NFS se comporte exactement comme les lecteurs connectés en local. Si les implémentations du client et du serveur NFS ne fournissent pas les sémantiques des systèmes de fichiers standards, cela peut poser des problèmes de fiabilité (voir http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html). En particulier, des écritures asynchrones (décalées dans le temps) sur le serveur NFS peuvent poser des soucis de fiabilité. Si possible, montez les systèmes de fichiers NFS en synchrone (sans cache) pour éviter tout problème. De même, le montage soft NFS n'est pas recommandé.
Les SAN (acronyme de Storage Area Networks) utilisent typiquement des protocoles de communication autres que NFS, et pourraient être sujet ou pas à des problèmes de ce type. Il est préférable de consulter la documentation du vendeur concernant les garanties de cohérence des données. PostgreSQL ne peut pas être plus fiable que le système de fichiers qu'il utilise.