17.5. Write Ahead Log
Voir aussi la Section 27.3,
« Configuration de WAL » pour les détails concernant
l'optimisation des des WAL.
-
fsync (boolean)
-
Si ce paramètre est activé, le serveur PostgreSQL™ tente de s'assurer que
les mises à jour sont écrites physiquement sur le disque en
exécutant des appels système fsync() ou toute autre méthode équivalente
(voir wal_sync_method).
Ceci permet de s'assurer que le cluster de bases de données
peut revenir à un état cohérent après une panne matérielle ou
du système d'exploitation.
Toutefois, l'utilisation de fsync()
a un impact sur les performances : lorsqu'une transaction est
validée, PostgreSQL™
doit attendre que le système d'exploitation vide les WAL sur
disque. Lorsque fsync est désactivé,
le système d'exploitation est autorisé à faire de son mieux
dans la mise en tampons, l'ordonnancement et le report des
écritures. Cependant, en cas de panne système, les résultats
des dernières transactions validées peuvent être en partie,
voire complètement, perdus. Dans le pire des cas, une
corruption irrécupérable des données peut survenir. (Une
panne du serveur de bases de données lui-même ne représente
pas
ici un facteur de
risque. Seul une panne système engendre un risque de
corruption.)
Du fait des risques encourus, il n'existe pas de paramétrage
universel pour fsync. Certains
administrateurs désactivent en permanence fsync alors que d'autres ne le désactivent que
pour les chargements initiaux importants de données puisqu'il
existe un point de redémarrage clairement défini si quelque
chose se passe mal. D'autres laissent fsync en permanence activé. Par défaut, il est
préférable d'activer fsync pour une
bénéficier d'une sécurité maximale. Si le système
d'exploitation, le matériel et la compagnie délectricité (ou
la sauvegarde sur batterie) sont dignes de confiance, la
désactivation de fsync peut être
envisagée.
Ce paramètre ne peut qu'être configuré dans le fichier
postgresql.conf ou indiqué sur la
ligne de commande. Si ce paramètre est désactivé (off), il est intéressant de désactiver aussi
full_page_writes.
-
wal_sync_method (string)
-
Méthode utilisée pour forcer les mises à jour des WAL sur le
disque. Si fsync est désactivé,
alors ce paramètre est inapplicable car les mises à jour ne
sont pas du tout forcées. Les valeurs possibles sont :
-
open_datasync (écrit les
fichiers WAL avec l'option O_DSYNC de open())
-
fdatasync (appelle fdatasync() à chaque validation)
-
fsync_writethrough (appelle
fsync() à chaque validation,
forçant une écriture de tous les caches disque en
écriture)
-
fsync (appelle fsync() à chaque validation)
-
open_sync (écrit les fichiers
WAL avec l'option O_SYNC de
open())
Toutes ces options ne sont pas disponibles sur toutes les
plateformes. La valeur par défaut est la première méthode de
la liste ci-dessus supportée par la plateforme. Les options
open_* utilisent aussi O_DIRECT s'il est disponible. Ce paramètre ne
peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de
commande.
-
full_page_writes (boolean)
-
Quand ce paramètre est activé, le serveur PostgreSQL™ écrit l'intégralité du
contenu de chaque page disque dans les WAL lors de la
première modification de cette page intervenant après un
point de vérification. Ceci est nécessaire car une écriture
de page en cours alors que survient une panne du système
d'exploitation peut n'être que partiellement effectuée, ce
qui conduit à à une page sur disque qui contient un mélange
d'anciennes et de nouvelles données. Les données de
modification de niveau ligne stockées habituellement dans les
WAL ne sont pas suffisantes pour restaurer complètement une
telle page lors de la récupération d'après panne. Le stockage
l'image de la page complète garantit une restauration
correcte de la page, mais au prix d'un accroissement de la
quantité de données à écrire dans les WAL. (Parce que la
relecture des WAL démarre toujours à un point de
vérification, il est suffisant de faire cela lors de la
première modification de chaque page survenant après un point
de vérification. De ce fait, une façon de réduire le coût
d'écriture de pages complètes consiste à augmenter le
paramètre réglant les intervalles entre points de
vérification.)
La désactivation de ce paramètre accélère les opérations
normales, mais peut aboutir à la corruption de la base de
données après une panne du système d'exploitation ou une
coupure de courant. Les risques sont similaires à la
désactivation de fsync, bien que
moindres. Ce paramètre peut être désactiver sans risque si le
matériel (contrôleur disque sur batterie) ou le logiciel de
gestion du système de fichiers (ReiserFS 4) réduit le risque
d'écritures partielles de pages à un niveau suffisament bas.
La désactivation de ce paramètre n'affecte pas l'utilisation
de l'archivage des WAL pour la récupération d'un instantané,
aussi appelé PITR (voir
Section 23.3, « Archivage continu et récupération
d'un instantané (PITR) »).
Ce paramètre ne peut qu'être configuré dans le fichier
postgresql.conf ou indiqué sur la
ligne de commande. Activé par défaut (on).
-
wal_buffers (integer)
-
Quantité de mémoire utilisée en mémoire partagée pour les
données WAL. La valeur par défaut est de 64 Ko. Ce paramètre
nécessite uniquement d'être assez important pour contenir
toutes les données WAL engendrées par une transaction
typique, car les données sont écrites sur le disque à chaque
validation de transaction. Ce paramètre n'est ajustable qu'au
lancement du serveur.
L'augmentation de ce paramètre peut conduire PostgreSQL™ à réclamer plus de
tampons partagés System V que ne
le permet la configuration par défaut du système
d'exploitation. Voir la Section 16.4.1,
« Mémoire partagée et sémaphore » pour les
informations sur la façon d'ajuster ces paramètres, si
nécessaire.
-
commit_delay (integer)
-
Délai entre l'enregistrement d'une validation dans le tampon
WAL et le vidage du tampon sur le disque, en microsecondes.
Un délai différent de zéro peut autoriser la validation de
plusieurs transactions en un seul appel système fsync() si la charge système est assez
importante pour que des transactions supplémentaires soient
prêtes dans l'intervalle donné. Mais le délai est perdu si
aucune autre transaction n'est prête à être validée. Du coup,
le délai n'est traité que si au moins commit_siblings autres transactions sont
actives au moment où le processus serveur a écrit son
enregistrement de validation. La valeur par défaut est zéro,
soit pas de délai.
-
commit_siblings (integer)
-
Nombre minimum de transactions concurrentes ouvertes en même
temps nécessaires avant d'attendre le délai commit_delay. Une valeur plus importante rend
plus probable le fait qu'au moins une autre transaction soit
prête à valider pendant le délai. La valeur par défaut est de
cinq transactions.
17.5.2. Points de vérification
-
checkpoint_segments (integer)
-
Distance maximale entre deux points de vérification
automatique des WAL, en segments de fichier de traces (chaque
segment fait normalement 16 Mo). La valeur par défaut est de
trois segments. Ce paramètre ne peut qu'être configuré dans
le fichier postgresql.conf ou
indiqué sur la ligne de commande.
-
checkpoint_timeout (integer)
-
Temps maximum entre deux points de vérification automatique
des WAL, en secondes. La valeur par défaut est de cinq
minutes. Ce paramètre ne peut qu'être configuré dans le
fichier postgresql.conf ou indiqué
sur la ligne de commande.
-
checkpoint_warning (integer)
-
Si deux points de vérification imposés par le remplissage des
fichiers segment interviennent dans un délai plus court que
celui indiqué par ce paramètre (ce qui laisse supposer qu'il
faut augmenter la valeur du paramètre checkpoint_segments), un message est écrit
dans le fichier de traces du serveur. Par défaut, 30
secondes. Une valeur nulle (0) désactive cet avertissement.
Ce paramètre ne peut qu'être configuré dans le fichier
postgresql.conf ou indiqué sur la
ligne de commande.
-
archive_command (string)
-
La commande shell à exécuter pour archiver un segment complet
de la série des fichiers WAL. Si cette chaîne est vide
(valeur par défaut), l'archivage des WAL est désactivé. Tout
%p dans la chaîne est remplacé par
le chemin du fichier à archiver et tout %f par le seul nom du fichier. (Le chemin est
relatif au répertoire de travail du serveur, c'est-à-dire le
répertoire de données du cluster.) %% est utilisé pour intégrer un caractère
% dans la commande. Pour plus
d'informations, voir la Section 23.3.1,
« Configurer l'archivage WAL ». Ce paramètre ne
peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de
commande.
Il est important que la commande ne renvoie un code de sortie
nul que si, et seulement si, elle réussit. Exemples :
archive_command = 'cp "%p" /mnt/server/archivedir/"%f"'
archive_command = 'copy "%p" /mnt/server/archivedir/"%f"' # Windows
-
archive_timeout (integer)
-
Le archive_command
n'est appelé que pour les segments WAL complets. De ce fait,
si le serveur n'engendre que peu de trafic WAL (ou que cela
arrive parfois), il se peut qu'un long moment s'écoule entre
la fin d'une transaction et son archivage sécurisé. Pour
limiter l'âge des données non encore archivées, archive_timeout peut être configuré pour
forcer le serveur à basculer périodiquement sur un nouveau
segment WAL. Lorsque ce paramètre est positif, le serveur
bascule sur un nouveau segment à chaque fois que archive_timeout secondes se sont écoulées
depuis le dernier changement de segment. Les fichiers
archivés clos par anticipation suite à une bascule imposée
sont toujours de la même taille que les fichiers complets. Il
est donc déconseillé de configurer un temps très court pour
archive_timeout -- cela va faire
exploser la taille du stockage des archives. Un paramétrage
d'archive_timeout de l'ordre de la
minute est habituellement raisonnable. Ce paramètre ne peut
qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de
commande.
|
Consommation des ressources
