Le mécanisme WAL est automatiquement disponible ; aucune action n'est requise de la part de l'administrateur excepté de s'assurer que l'espace disque requis par les journaux de transaction soit présent et que tous les réglages soient faits (regardez la Section 30.4).
Des enregistrements WAL sont ajoutés aux journaux
WAL, enregistrement après enregistrement. La position
d'insertion est donnée par le Log Sequence Number (LSN)
qui est un décalage d'octet dans les journaux de transactions, décalage
s'incrémentant de manière monotone à chaque enregistrement. Les valeurs du
LSN sont renvoyées en tant que type de données pg_lsn
. Les valeurs peuvent
être comparées pour calculer le volume de données WAL
les séparant, permettant ainsi de mesurer l'avancement de la réplication et
de la restauration.
Les journaux de transaction sont stockés dans le répertoire
pg_wal
sous le répertoire de données, comme un ensemble
de fichiers, chacun d'une taille de 16 Mo généralement (cette taille
pouvant être modifiée en précisant une valeur pour l'option
--with-wal-segsize
de configure lors de la construction
du serveur). Chaque fichier est divisé en pages de généralement 8 Ko
(cette taille pouvant être modifiée en précisant une valeur pour l'option
--with-wal-blocksize
de configure). Les en-têtes de
l'entrée du journal sont décrites dans
access/xlogrecord.h
; le contenu de l'entrée dépend
du type de l'événement qui est enregistré. Les fichiers
sont nommés suivant un nombre qui est toujours incrémenté et qui
commence à 000000010000000000000001
. Les nombres ne
bouclent pas, mais cela prendra beaucoup de temps pour épuiser le stock de
nombres disponibles.
Il est avantageux que les journaux soient situés sur un autre disque que
celui des fichiers principaux de la base de données. Cela peut
se faire en déplaçant le répertoire
pg_wal
vers un autre emplacement (alors que
le serveur est arrêté) et en créant un lien
symbolique de l'endroit d'origine dans le répertoire principal de
données au nouvel emplacement.
Le but de WAL est de s'assurer que le journal est écrit avant l'altération des entrées dans la base, mais cela peut être mis en échec par les disques qui rapportent une écriture réussie au noyau quand, en fait, ils ont seulement mis en cache les données et ne les ont pas encore stockés sur le disque. Une coupure de courant dans ce genre de situation peut mener à une corruption irrécupérable des données. Les administrateurs devraient s'assurer que les disques contenant les journaux de transaction de PostgreSQL ne produisent pas ce genre de faux rapports. (Voir Section 30.1.)
Après qu'un point de contrôle ait été fait et que le journal ait été
écrit, la position du point de contrôle est sauvegardée dans le
fichier pg_control
. Donc, au début de la
récupération, le serveur lit en premier
pg_control
et ensuite l'entrée du point de
contrôle ; ensuite, il exécute l'opération REDO en parcourant vers
l'avant à partir de la position du journal indiquée dans l'entrée du
point de contrôle. Parce que l'ensemble du contenu des pages de
données est sauvegardé dans le journal à la première modification de
page après un point de contrôle (en supposant que full_page_writes n'est pas désactivé), toutes les pages
changées depuis le point de contrôle seront restaurées dans un état cohérent.
Pour gérer le cas où pg_control
est corrompu, nous
devons permettre le parcours des segments de journaux
existants en ordre inverse -- du plus récent au plus ancien -- pour
trouver le dernier point de vérification. Ceci n'a pas encore été implémenté.
pg_control
est assez petit (moins d'une page disque)
pour ne pas être sujet aux problèmes d'écriture partielle et, au moment où
ceci est écrit, il n'y a eu aucun rapport d'échecs de la base de données
uniquement à cause de son incapacité à lire pg_control
.
Donc, bien que cela soit théoriquement un point faible,
pg_control
ne semble pas être un problème en pratique.