| 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 |