Documentation PostgreSQL 7.4.29 | ||||
---|---|---|---|---|
Pr�c�dent | Arri�re rapide | Chapitre 25. Write-Ahead Logging (WAL) | Avance rapide | Suivant |
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�.
Pr�c�dent | Sommaire | Suivant |
Configuration de WAL | Niveau sup�rieur | Tests de r�gression |