25.3. Internes

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

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 g�n�ralement. Chaque segment est divis� en pages de g�n�ralement 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 � 000000010000000000000000. Les nombres ne bouclent pas actuellement, 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 de 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 mis en �chec 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 ait �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.

Pour g�rer le cas o� pg_control est corrompu, nous devons permettre le parcours des segments de journaux existants en ordre inverse — du plus r�cent au plus ancien — pour trouver le dernier point de v�rification. Ceci n'a pas encore �t� impl�ment�. pg_control est assez petit (moins d'une page disque) pour ne pas �tre sujet aux probl�mes d'�criture partielle et, au moment o� ceci est �crit, il n'y a eu aucun rapport d'�checs de la base de donn�es uniquement � cause de son incapacit� � lire pg_control. Donc, bien que cela soit th�oriquement un point faible, pg_control ne semble pas �tre un probl�me en pratique.