IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

55. Stockage physique de la base de données

Ce chapitre fournit un aperçu du format de stockage physique utilisé par les bases de données PostgreSQL™.

55.1. Emplacement des fichiers de la base de données

Cette section décrit le format de stockage au niveau des fichiers et répertoires.

Toutes les données nécessaires à un groupe de bases de données sont stockées dans le répertoire data du groupe, habituellement référencé en tant que PGDATA (d'après le nom de la variable d'environnement qui peut être utilisé pour le définir). Un emplacement courant pour PGDATA est /var/lib/pgsql/data. Plusieurs groupes, gérés par différentes instances du serveur, peuvent exister sur la même machine.

Le répertoire PGDATA contient plusieurs sous-répertoires et fichiers de contrôle, comme indiqué dans le Tableau 55.1, « Contenu de PGDATA ». En plus de ces éléments requis, les fichiers de configuration du groupe, postgresql.conf, pg_hba.conf et pg_ident.conf sont traditionnellement stockés dans PGDATA (bien qu'il soit possible de les conserver ailleurs à partir de la version 8.0 de PostgreSQL™).

Tableau 55.1. Contenu de PGDATA

Élément Description
PG_VERSION Un fichier contenant le numéro de version majeur de PostgreSQL
base Sous-répertoire contenant les sous-répertoires par base de données
global Sous-répertoire contenant les tables communes au groupe, telles que pg_database
pg_clog Sous-répertoire contenant les données d'état de validation des transactions
pg_multixact Sous-répertoire contenant des données sur l'état des multi-transactions (utilisé pour les verrous de lignes partagées)
pg_notify Sous-répertoire contenant les données de statut de LISTEN/NOTIFY
pg_serial Sous-répertoire contenant des informations sur les transactions sérialisables validées
pg_stat_tmp Sous-répertoire contenant les fichiers temporaires pour le sous-système des statistiques
pg_subtrans Sous-répertoire contenant les données d'états des sous-transaction
pg_tblspc Sous-répertoire contenant les liens symboliques vers les espaces logiques
pg_twophase Sous-répertoire contenant les fichiers d'état pour les transactions préparées
pg_xlog Sous-répertoire contenant les fichiers WAL (Write Ahead Log)
postmaster.opts Un fichier enregistrant les options en ligne de commande avec lesquelles le serveur a été lancé la dernière fois
postmaster.pid Un fichier verrou contenant l'identifiant du processus postmaster en cours d'exécution (PID), le chemin du répertoire de données, la date et l'heure du lancement de postmaster, le numéro de port, le chemin du répertoire du socket de domaine Unix (vide sous Windows), la première adresse valide dans listen_address (adresse IP ou *, ou vide s'il n'y a pas d'écoute TCP) et l'identifiant du segment de mémoire partagé (ce fichier est supprimé à l'arrêt du serveur)

Pour chaque base de données dans le groupe, il existe un sous-répertoire dans PGDATA/base, nommé d'après l'OID de la base de données dans pg_database. Ce sous-répertoire est l'emplacement par défaut pour les fichiers de la base de données; en particulier, ses catalogues système sont stockés ici.

Chaque table et index est stocké dans un fichier séparé. Pour les relations ordinaires, ces fichiers sont nommés d'après le numéro filenode de la table ou de l'index. Ce numéro est stocké dans pg_class.relfilenode. Pour les relations temporaires, le nom du fichier est de la forme tBBB_FFF, où BBB est l'identifiant du processus serveur qui a créé le fichier, et FFF et le numéro filenode. Dans tous les cas, en plus du fichier principal (aussi appelé main fork), chaque table et index a une carte des espaces libres (voir Section 55.3, « Carte des espaces libres »), qui enregistre des informations sur l'espace libre disponible dans la relation. La carte des espaces libres est stockée dans un fichier dont le nom est le numéro filenode suivi du suffixe _fsm. Les tables ont aussi une carte des visibilités, stockée dans un fichier de suffixe _vm, pour tracer les pages connues comme n'ayant pas de lignes mortes. La carte des visibilités est décrite dans Section 55.4, « Carte de visibilité ». Les tables non tracées et les index disposent d'un troisième fichier, connu sous le nom de fichier d'initialisation. Son nom a pour suffixe _init (voir Section 55.5, « The Initialization Fork »).

[Attention]

Attention

Notez que, bien que le filenode de la table correspond souvent à son OID, cela n'est pas nécessairement le cas; certaines opérations, comme TRUNCATE, REINDEX, CLUSTER et quelques formes d'ALTER TABLE, peuvent modifier le filenode tout en préservant l'OID. Évitez de supposer que filenode et OID sont identiques. De plus, pour certains catalogues système incluant pg_class lui-même, pg_class.relfilenode contient zéro. Le numéro filenode en cours est stocké dans une structure de données de bas niveau, et peut être obtenu avec la fonction pg_relation_filenode().

Quand une table ou un index dépasse 1 Go, il est divisé en segments d'un Go. Le nom du fichier du premier segment est identique au filenode ; les segments suivants sont nommés filenode.1, filenode.2, etc. Cette disposition évite des problèmes sur les plateformes qui ont des limitations sur les tailles des fichiers. (Actuellement, 1 Go est la taille du segment par défaut. Cette taille est ajustable en utilisant l'option --with-segsize pour configure avant de construire PostgreSQL™.) En principe, les fichiers de la carte des espaces libres et de la carte de visibilité pourraient aussi nécessiter plusieurs segments, bien qu'il y a peu de chance que cela arrive réellement.

Une table contenant des colonnes avec des entrées potentiellement volumineuses aura une table TOAST associée, qui est utilisée pour le stockage de valeurs de champs trop importantes pour conserver des lignes adéquates. pg_class.reltoastrelid établit un lien entre une table et sa table TOAST, si elle existe. Voir Section 55.2, « TOAST » pour plus d'informations.

Le contenu des tables et des index est discuté plus en détails dans Section 55.6, « Emplacement des pages de la base de données ».

Les tablespaces rendent ce scénario plus compliqués. Chaque espace logique défini par l'utilisateur contient un lien symbolique dans le répertoire PGDATA/pg_tblspc, pointant vers le répertoire physique du tablespace (celui spécifié dans la commande CREATE TABLESPACE). Ce lien symbolique est nommé d'après l'OID du tablespace. À l'intérieur du répertoire du tablespace, il existe un sous-répertoire avec un nom qui dépend de la version du serveur PostgreSQL™, comme par exemple PG_9.0_201008051. (La raison de l'utilisation de ce sous-répertoire est que des versions successives de la base de données puissent utiliser le même emplacement indiqué par CREATE TABLESPACE sans que cela provoque des conflits.) À l'intérieur de ce répertoire spécifique à la version, il existe un sous-répertoire pour chacune des bases de données contenant des éléments dans ce tablespace. Ce sous-répertoire est nommé d'après l'OID de la base. Les tables et les index sont enregistrés dans ce répertoire et suivent le schéma de nommage des filenodes. Le tablespace pg_default n'est pas accédé via pg_tblspc mais correspond à PGDATA/base. De façon similaire, le tablespace pg_global n'est pas accédé via pg_tblspc mais correspond à PGDATA/global.

La fonction pg_relation_filepath() affiche le chemin entier (relatif à PGDATA) de toute relation. Il est souvent utile pour ne pas avoir à se rappeler toutes les différentes règles ci-dessus. Gardez néanmoins en tête que cette fonction donne seulement le nom du premier segment du fichier principal de la relation -- vous pourriez avoir besoin d'ajouter le numéro de segment et/ou les extensions _fsm ou _vm pour trouver tous les fichiers associés avec la relation.

Les fichiers temporaires (pour des opérations comme le tri de plus de données que ce que la mémoire peut contenir) sont créés à l'intérieur de PGDATA/base/pgsql_tmp, ou dans un sous-répertoire pgsql_tmp du répertoire du tablespace si un tablespace autre que pg_default est indiqué pour eux. Le nom du fichier temporaire est de la forme pgsql_tmpPPP.NNN, où PPP est le PID du serveur propriétaire et NNN distingue les différents fichiers temporaires de ce serveur.