25.4. Internes

WAL est automatiquement disponible ; aucune action n'est requise de la part de l'administrateur excepté de s'assurer que l'espace disque supplémentaire requis par les journaux WAL est présent et que tous les réglages sont faits (regardez la Section 25.3).

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. Chaque segment est divisé en pages de 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 à 0000000000000000. Les nombres ne bouclent pas à présent, 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 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 renversé 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 a é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.

Utiliser pg_control, pour obtenir la position du point de contrôle, accélère le processus de récupération mais pour traiter une possible corruption de pg_control, nous devrions en fait implémenter la lecture de segments de journaux dans l'ordre inverse -- du plus jeune au plus vieux -- afin de trouver le dernier point de contrôle. Ceci n'a pas encore été implémenté.