| Documentation PostgreSQL 8.0.25 | ||||
|---|---|---|---|---|
| Précédent | Arrière rapide | Avance rapide | Suivant | |
Write-Ahead Logging (WAL) est une approche conventionnelle pour l'écriture d'un journal de transactions. Sa description détaillée peut être trouvée dans la plupart (si ce n'est tous) des livres sur le traitement transactionnel. Brièvement, le concept central des WAL est d'effectuer les changements des fichiers de données (où résident les tables et les index) uniquement après que ces changements ont été écrits dans un journal, c'est-à-dire quand l'enregistrement du journal décrivant les changements a été écrit vers le stockage permanent. Si nous suivons cette procédure, nous n'avons pas besoin d'écrire les pages de données vers le disque à chaque validation de transaction car nous savons que, dans l'éventualité d'une défaillance, nous serons capables de récupérer la base de données en utilisant le journal : chaque changement qui n'a pas été appliqué aux pages de données peut être ré-exécuté depuis les enregistrements du journal (ceci est une récupération roll-forward, aussi connue sous le nom de REDO).
Le premier avantage majeur en utilisant les WAL
est la réduction significative du nombre d'écritures sur le disque
puisque seul le journal des transactions a besoin d'être écrit sur le
disque au moment où la transaction est validée plutôt que d'écrire dans chaque fichier de
données modifié par la transaction. Dans un environnement
multi-utilisateurs, la validation de nombreuses transactions peut être
accomplie avec un seul fsync() du journal. De plus, ce
dernier est écrit séquentiellement et donc, le coût de
synchronisation du journal est largement moindre que le coût d'écriture des
pages de données. Ceci est spécialement vrai pour les serveurs gérant
beaucoup de petites transactions touchant différentes parties du stockage de
données.
Le second avantage est la cohérence des pages de données. La vérité est qu'avant WAL, PostgreSQL n'était pas capable de garantir la cohérence en cas de défaillance (crash). Avant WAL, une défaillance quelconque durant l'écriture pouvait être le résultat :
de lignes d'un index pointant vers des lignes inexistantes d'une table ;
de lignes perdues d'un index dans des opérations de séparation ;
de tables ou de contenu de pages d'index totalement corrompues à cause d'une écriture partielle des pages de données
Les problèmes avec les index (les problèmes 1 et 2) auraient pû être
corrigés avec des appels supplémentaires à fsync mais
il n'est pas évident de traiter le dernier cas sans WAL.
WAL sauve le contenu entier de la page de données dans le
journal si cela est requis pour assurer la cohérence de la page et permettre
ainsi la récupération après une défaillance.
Enfin, les WAL rendent possible le support de sauvegarde en ligne et de récupération à un moment, comme décrit dans Section 22.3. En archivant les données WAL, nous pouvons supporter le retour à tout instant couvert par les données disponibles dans les WAL : nous installons simplement une ancienne sauvegarde physique de la base de données et nous rejouons les journaux WAL jusqu'au moment désiré. Qui plus est, la sauvegarde physique n'a pas besoin d'être une image instantanée de l'état de la base de données — si elle a été faire pendant une période de temps, alors rejouer les journaux WAL pour cette période corrigera toute inconsistance interne.
| Précédent | Sommaire | Suivant |
| Échec sur disque plein | Niveau supérieur | Configuration de WAL |