25.3. Internes

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 WAL soit présent et que tous les réglages soient faits (regardez la Section 25.2).

Les journaux WAL sont stockés dans le répertoire pg_xlog sous le répertoire de données, comme un ensemble de fichiers segments, chacun d'une taille de 16 Mo généralement. Chaque segment est divisé en pages de généralement 8 Ko. Les en-têtes de l'entrée du journal sont décrites dans access/xlog.h ; le contenu de l'entrée dépend du type de l'événement qui est enregistré. Les fichiers segments sont nommés avec un chiffre qui est toujours incrémenté et qui commence à 000000010000000000000000. Les nombres ne bouclent pas actuellement, mais cela devrait prendre beaucoup de temps pour épuiser le stock de nombres disponibles.

Les tampons WAL et la structure de contrôle sont situés dans la mémoire partagée et sont manipulés par les processus enfants du serveur. Ils sont protégés par des verrous légers. La demande en mémoire partagée est dépendante du nombre de tampons. La taille par défaut des tampons WAL est de 8 tampons de 8 Ko chacun, soit 64 Ko au total.

Il est avantageux que le journal soit situé sur un autre disque que celui des fichiers principaux de la base de données. Cela peut se réaliser en déplaçant le répertoire pg_xlog vers un autre emplacement (alors que le serveur est arrêté, naturellement) 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, s'assurer que le journal est écrit avant l'altération des entrées dans la base, peut être mis en échec par les lecteurs des disques qui faussement 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ées sur le disque. Une coupure de courant dans ce genre de situation peut toujours mener à la corruption irrécupérable des données. Les administrateurs devraient s'assurer que les disques contenant les journaux WAL de PostgreSQL ne produisent pas ce genre de faux rapports.

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, quand la restauration doit se faire, 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, 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.