| Documentation PostgreSQL 7.4.29 | ||||
|---|---|---|---|---|
| Précédent | Arrière rapide | Avance rapide | Suivant | |
Write-Ahead Logging (WAL) est une approche standard 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 que les changements des fichiers de données (où résident les tables et les index) doivent être effectués uniquement après que ces changements aient été écrits dans un journal, c'est-à-dire quand l'enregistrement du journal 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 sera d'abord refait depuis les enregistrements du journal (ceci est une récupération roll-forward, aussi connue sous le nom de REDO) et ensuite les changements effectués par des transactions non validées seront supprimés des pages de données (récupération roll-backward, UNDO).
Le premier avantage évident en utilisant les WAL
est la réduction significative du nombre d'écritures sur le disque
puisque uniquement le journal des transactions a besoin d'être écrit sur le
disque au moment où la transaction est validée ; 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.
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 la récupération après défaillance.
| Précédent | Sommaire | Suivant |
| Échec sur disque plein | Niveau supérieur | Avantages futurs |