Voir aussi la Section 30.5 pour plus d'informations sur la configuration de ces paramètres.
wal_level
(enum
) #
wal_level
détermine la quantité d'informations
écrite dans les journaux de transactions.
wal_level
détermine la quantité d'informations qui sera
écrite dans les WAL. La valeur par défaut est replica
,
qui écrit suffisamment de données pour pouvoir utiliser l'archivage des
WAL ainsi que la réplication, y compris exécuter des requêtes en lecture
seule sur un serveur secondaire. minimal
supprime toute
la journalisation à l'exception des informations nécessaire pour pouvoir
effectuer une récupération suite à un arrêt brutal ou un arrêt immédiat.
Enfin, logical
ajoute les informations
nécessaires au support du décodage logique. Chaque niveau inclut les
informations tracées dans les niveaux inférieurs.
Ce paramètre peut seulement être configuré au lancement du
serveur.
Le niveau minimal
génère le moins de volume WAL. Il ne
trace aucune ligne pour les relations permanentes dans des transactions qui
les ont créées ou réécrites. Ceci peut rendre certaines opérations bien
plus rapides (voir Section 14.4.7). Les opérations qui
initient cette optimisation incluent :
CREATE TABLE AS |
CREATE INDEX |
ALTER ... SET TABLESPACE |
CLUSTER |
COPY dans des tables qui ont été créées ou
tronquées dans la même transaction |
CREATE TABLE |
REFRESH MATERIALIZED VIEW
(without CONCURRENTLY ) |
REINDEX |
TRUNCATE |
Mais, du coup, les journaux au niveau minimal ne contiennent pas suffisamment
d'informations pour reconstruire les données à partir d'une sauvegarde
de base et des journaux de transactions. Donc, les niveaux
replica
ou supérieurs doivent
être utilisés pour activer l'archivage continue des journaux de transactions
(archive_mode) et la réplication binaire en flux.
En fait, le serveur ne démarrera pas dans ce mode si
max_wal_senders
est différent de zéro.
Notez que changer wal_level
à la valeur
minimal
rend les sauvegardes de base précédentes inutilisables
pour une restauration PITR et pour des serveurs secondaires.
Dans le niveau logical
, les mêmes informations sont
enregistrées que pour le mode replica
. Des
informations supplémentaires sont ajoutées pour extraire les
modifications logiques depuis les journaux de transactions. En utilisant
le niveau logical
, le volume des journaux de
transactions va augmenter, tout particulièrement si plusieurs tables
sont configurées pour REPLICA IDENTITY FULL
et que
de nombreux UPDATE
et DELETE
sont
exécutés.
Dans les versions antérieures à la 9.6, ce paramètre autorise aussi les
valeurs archive
et hot_standby
. Elles
sont toujours acceptées mais sont converties silencieusement en
replica
.
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 à l'aide d'appels système fsync()
ou de méthodes équivalentes (voir wal_sync_method).
Cela 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.
Bien que désactiver fsync
améliore fréquemment les
performances, cela peut avoir pour conséquence une corruption des
données non récupérables dans le cas d'une perte de courant ou d'un
crash du système. Donc, il est seulement conseillé de désactiver
fsync
si vous pouvez facilement recréer la base de
données complète à partir de données externes.
Quelques exemples de circonstances permettant de désactiver
fsync
: le chargement initial d'une nouvelle
instance à partir d'une sauvegarde, l'utilisation de l'instance pour
traiter un flot de données après quoi la base sera supprimée puis recréée,
la création d'un clone d'une base en lecture seule, clone qui serait
recréé fréquemment et n'est pas utilisé pour du failover. La haute
qualité du matériel n'est pas une justification suffisante pour
désactiver fsync
.
Pour une restauration fiable lors de la modification de
fsync
de off à on, il est nécessaire de forcer tous
les tampons modifiés disponibles dans le cache du noyau à être écrits
sur un stockage durable. Ceci peut se faire alors que l'instance est
arrêtée ou lorsque fsync
est activé en exécutant initdb
--sync-only
, en exécutant sync
, en démontant
le système de fichiers ou en redémarrant le serveur.
Dans de nombreuses situations, désactiver synchronous_commit pour les transactions non critiques
peut fournir une grande partie des performances de la désactivation de
fsync
, sans les risques associés de corruption de
données.
fsync
ne peut être configuré que 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.
synchronous_commit
(enum
) #
Indique quel traitement des WAL doit se faire avant que le serveur de
bases de données ne renvoie une indication de « succès » au
client. Les valeurs valides sont remote_apply
,
on
(par défaut), remote_write
,
local
et off
.
Si synchronous_standby_names
est vide, les seules
valeurs sensées sont on
et
off
; remote_apply
,
remote_write
et local
fournissent
toutes le même niveau de synchronisation locale que
on
. Le comportement local de tous les modes différents
de off
est d'attendre le vidage local sur disque des
WAL. Dans le mode off
, il n'y a pas d'attente, donc il
peut y avoir un délai entre le retour du succès au client et le fait que
la transaction est garantie d'être sécurisée contre un crash du serveur.
(Le délai maximum est de trois fois wal_writer_delay.)
Contrairement à fsync, la configuration de ce
paramètre à off
n'implique aucun risque
d'incohérence dans la base de données : un arrêt brutal du système
d'exploitation ou d'une base de données peut résulter en quelques
transactions récentes prétendument validées perdues malgré tout.
Cependant, l'état de la base de données est identique à celui obtenu
si les transactions avaient été correctement annulées. C'est pourquoi
la désactivation de synchronous_commit
est une
alternative utile quand la performance est plus importante que la
sûreté de la transaction. Pour plus de discussion, voir Section 30.4.
Si synchronous_standby_names n'est pas vide,
synchronous_commit
contrôle aussi si les validations
de transactions attendront que leurs enregistrements WAL soient traités
sur le serveur secondaire.
Quand il est configuré à remote_apply
, les validations
attendront la réponse des serveurs secondaires synchrones indiquant
qu'ils ont bien reçu l'enregistrement de validation de la transaction et
qu'ils l'ont bien appliqués, pour qu'elle devienne visible aux requêtes
sur les serveurs secondaires, et aussi écrites sur un stockage durable.
Ceci causera les plus gros délais de validation par rapport aux
configurations précédentes car il faut attendre le rejeu des WAL. Quand
il est configuré à on
, les validations attendent que
les réponses des serveurs secondaires synchrones indiquent qu'ils ont
reçu l'enregistrement de validation de la transaction et qu'ils l'ont
écrit sur un stockage durable. Ceci assure que la transaction ne sera pas
perdu sauf si le primaire et les secondaires synchrones souffrent de
corruption au niveau disque. Quand il est configuré à
remote_write
, les validations attendront que les
réponses des serveurs secondaires synchrones indiquent avoir reçu
l'enregistrement de validation de la transaction et l'avoir écrit sur
disque. Ce paramétrage assure de la préservation des données si une
instance secondaire de PostgreSQL s'arrête
brutalement, mais pas si le serveur secondaire souffre d'un crash au
niveau du système d'exploitation parce que les données n'ont pas
nécessairement atteint un stockage durable sur le secondaire. Le
paramétrage local
fait que les validations attendent
uniquement le vidage local sur disque, mais n'attendent pas le retour des
serveurs secondaires synchrones. Ceci n'est généralement pas souhaité
quand la réplication synchrone est utilisée mais est fourni pour être
complet.
Ce paramètre peut être changé à tout moment ; le comportement
pour toute transaction est déterminé par la configuration en cours
lors de la validation. Il est donc possible et utile d'avoir certaines
validations validées en synchrone et d'autres en asynchrone.
Par exemple, pour réaliser une validation asynchrone de transaction
à plusieurs instructions avec une valeur par défaut inverse, on exécute
l'instruction SET LOCAL synchronous_commit TO OFF
dans la transaction.
Tableau 20.1 résume les possibilités
de configuration de synchronous_commit
.
Tableau 20.1. Modes pour synchronous_commit
synchronous_commit | validation locale durable | valide durable du standby après un crash de PG | valide durable du standby après un crash de l'OS | cohérence des requêtes sur le standby |
---|---|---|---|---|
remote_apply | • | • | • | • |
on | • | • | • | |
remote_write | • | • | ||
local | • | |||
off |
wal_sync_method
(enum
) #
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 des journaux de transactions 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 le mode write-through 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 les possibilités ne sont pas disponibles sur toutes les plateformes.
La valeur par défaut est la première méthode de cette liste supportée par la
plateforme, à l'exception de fdatasync
qui est la valeur
par défaut de Linux et FreeBSD.
La valeur par défaut n'est pas nécessairement la meilleure, il est possible
de devoir changer celle-ci ou tout autre aspect de votre configuration
système pour s'assurer d'une configuration résistante aux crashs ou
pour atteindre des performances optimales. Ces aspects sont discutées sur
Section 30.1. Ce paramètre ne peut être modifié que
dans le fichier postgresql.conf
ou dans la ligne de commande.
full_page_writes
(boolean
) #Quand ce paramètre est activé, le serveur écrit l'intégralité du contenu de chaque page disque dans les WAL lors de la première modification de cette page qui intervient après un point de vérification. C'est nécessaire car l'écriture d'une page lors d'un plantage du système d'exploitation peut n'être que partielle, 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 qui suit la panne. Le stockage de 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 suffit 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 soit à une corruption impossible à corriger soit à une
corruption silencieuse, après un échec système. Les risques sont
similaires à la désactivation de fsync
, bien que
moindres. Sa désactivation devrait se faire en se basant sur les mêmes
recommandations que cet autre paramètre.
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 26.3).
Ce paramètre ne peut être configuré que dans le fichier
postgresql.conf
ou indiqué sur la ligne de commande.
Activé par défaut (on
).
wal_log_hints
(boolean
)
#
Quand ce paramètre a la valeur on
, le serveur
PostgreSQL écrit le contenu entier de chaque
page disque dans les journaux de transactions lors de la première
modification de cette page après un checkpoint, même pour des
modifications non critiques comme les hint bits.
Si les sommes de contrôle sont activées, la mise à jour des hint bits est toujours enregistrée dans les journaux et ce paramètre est ignoré. Vous pouvez utiliser ce paramètre pour tester le volume supplémentaire de journaux induit par l'activiation des sommes de contrôle sur les fichiers de données.
Ce paramètre n'est configurable qu'au démarrage du serveur. La valeur
par défaut vaut off
.
wal_compression
(enum
)
#
Ce paramètre active la compression des journaux de transactions en
utilisant la méthode de compression indiquée. Lorsque la compression est
activée, le serveur PostgreSQL compresse une
image d'une page complète écrite dans les WAL lorsque full_page_writes est à on ou durant une sauvegarde de base.
Une image compressée d'une page sera décompressée durant le rejeu des WAL.
Les méthodes acceptées sont pglz
, lz4
(si PostgreSQL a été compilé avec
--with-lz4
) et zstd
(si
PostgreSQL a été compilé avec
--with-zstd
). La valeur par défaut est à
off
. Seuls les superutilisateurs et les utilisateurs
disposant des droits SET
appropriés peuvent modifier ce
paramètre.
Activer la compression peut réduire le volume des WAL sans augmenter le risque de données corrompues irrécupérables, mais avec l'effet d'avoir un coût supplémentaire en terme de puissance CPU sur la compression durant l'écriture des WAL et sur la décompression lors du rejeu des WAL.
wal_init_zero
(boolean
)
#
Si configuré à on
(la valeur par défaut), cette option
fait que les nouveaux journaux de transactions sont remplis de zéro. Sur
certains systèmes de fichiers, ceci assure que la place est allouée avant
qu'il ne soit nécessaire d'écrire les enregistrements WAL. Néanmoins, les
systèmes de fichiers Copy-On-Write (COW)
pourraient ne pas bénéficier de cette technique, donc l'option est donnée
pour éviter ce travail inutile. Si configuré à off
,
seul l'octet final est écrit quand le fichier est créé pour qu'il ait la
taille attendue.
wal_recycle
(boolean
)
#
Si configuré à on
(la valeur par défaut), cette option
fait que les fichiers WAL sont recyclés en les renommant, pour éviter
d'avoir à créer de nouveaux fichiers. Sur les systèmes de fichiers COW,
il pourrait être plus rapide d'en créer de nouveaux, donc l'option est
donnée pour désactiver ce comportement.
wal_buffers
(integer
) #
La quantité de mémoire partagée utilisée pour les données des
journaux de transactions qui n'ont pas encore été écrites sur
disque. La configuration par défaut de -1 sélectionne une taille
égale à 1/32 (environ 3%) de shared_buffers, mais pas moins de
64kB
, et pas plus que la taille d'un journal
de transactions, soit généralement 16MB
. Cette
valeur peut être configurée manuellement si le choix automatique
est trop élevé ou trop faible, mais tout valeur positive inférieure
à 32kB
sera traitée comme étant exactement
32kB
.
Si cette valeur est spécifiée sans unité, elle est prise en tant que
nombre de blocs de journaux de transactions, autrement dit
XLOG_BLCKSZ
octets, typiquement 8 Ko. Ce paramètre ne
peut être configuré qu'au démarrage du serveur.
Le contenu du cache des journaux de transactions est écrit sur le disque à chaque validation d'une transaction, donc des valeurs très importantes ont peu de chance d'apporter un gain significatif. Néanmoins, configurer cette valeur à au moins quelques mégaoctets peut améliorer les performances en écriture sur un serveur chargé quand plusieurs clients valident en même temps. La configuration automatique sélectionnée par défaut avec la valeur -1 devrait être convenable.
wal_writer_delay
(integer
) #
Indique à quelle fréquence (une durée) le walwriter vide les journaux sur disque. Après
avoir vidé les journaux sur disque, ce processus s'endort pour la durée
indiquée par le paramètre wal_writer_delay
sauf s'il est réveillé
par une transaction validée en asynchrone. Dans le cas où le dernier
vidage est survenu il y a moins de wal_writer_delay
millisecondes et que moins de wal_writer_flush_after
octets ont été produits dans les WAL depuis, le WAL est seulement écrit via le
système d'exploitation mais pas forcément écrit sur disque.
Si cette valeur est spécifiée sans unité, elle est considérée être en millisecondes. La valeur par
défaut est 200 millisecondes (200ms
). Notez que sur de
nombreux systèmes, la résolution réelle du délai d'endormissement est de
10 millisecondes ; configurer wal_writer_delay
à
une valeur qui n'est pas un multiple de 10 pourrait avoir le même
résultat que de le configurer au prochain multiple de 10. Ce paramètre
est seulement configurable dans le fichier
postgresql.conf
ainsi que sur la ligne de commande
du serveur.
wal_writer_flush_after
(integer
)
#
Indique à quelle fréquence (une quantité) le walwriter vide les journaux
sur disque. Dans le cas où le dernier vidage est arrivé il y a moins de
wal_writer_delay
millisecondes et que moins de
wal_writer_flush_after
octets de WAL ont été produits
depuis, les WAL sont seulement écrit via le système d'exploitation, et
pas forcé sur disque. Si wal_writer_flush_after
est
configuré à 0
, le WAL est écrit et vidé à chaque fois
que le walwriter doit écrire dans un WAL. Si cette valeur est indiquée
sans unité, est est considérée comme un nombre de blocs dans les journaux
de transactions, autrement dit XLOG_BLCKSZ
octets,
typiquement 8 Ko. La valeur par défaut est 1MB
. Ce
paramètre est seulement configurable dans le fichier
postgresql.conf
ainsi que sur la ligne de commande
du serveur.
wal_skip_threshold
(integer
)
#
Quand wal_level
vaut minimal
et une
transaction valide après création et réécriture une table permanente, ce
paramètre détermine comment les nouvelles données persistent. Si la
donnée est plus petit que ce paramétrage, l'écrire dans les journaux de
transactions ; sinon, utiliser une demande de synchronisation
(fsync) des fichiers affectés. Suivant les propriétés de votre stockage,
augmenter ou abaisser cette valeur pourrait aider si de telles
validations de données ralentissent les transactions en cours. Si cette
valeur est indiquée sans unité, elle est considérée être un nombre de Ko.
La valeur par défaut est de deux mégaoctets (2MB
).
commit_delay
(integer
) #
Configurer commit_delay
ajoute un délai
avant qu'un vidage du journal de transactions ne soit effectué. Ceci
peut améliorer les performances de la validation en groupe en permettant
la validation d'un grand nombre transactions en un seul vidage des
journaux, si la charge système est suffisamment importante pour que
des transactions supplémentaires soient prêt ç être valider dans le
même intervalle. Néanmoins, cela augmente aussi la latence jusqu'à
la valeur de commit_delay
pour chaque vidage de
journaux. Comme le délai est perdu si aucune autre transaction n'est
prête à être validée, un délai n'est respecté que si au moins
commit_siblings
autres transactions sont actives
quand un vidage doit être initié. De plus, aucun délai ne sera pris
en compte si fsync
est désactivé. Si cette valeur
est indiquée sans unité, elle est considérée comme un nombre de
microsecondes. La valeur par défaut de commit_delay
est zéro (aucun délai). Seuls les superutilisateurs et les utilisateurs
disposant des droits SET
appropriés peuvent modifier
cette configuration.
Dans les versions de PostgreSQL antérieures
à la 9.3, commit_delay
se comportait différemment
et était bien moins efficace : il n'affectait que les validations
plutôt que les vidages de journaux et attendait que le délai complet
soit passé même si le vidage du journal était terminé avant. À partir
de PostgreSQL 9.3, le premier processus prêt
à vider le journal attend pendant l'intervalle configuré alors que les
autres processus attendent que le premier termine l'opération de vidage.
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.
checkpoint_timeout
(integer
) #
Temps maximum entre deux points de vérification automatique des WAL.
Si cette valeur est indiquée sans unité, elle est considérée comme un nombre
de secondes. L'intervalle valide se situe entre 30 secondes et un jour. La
valeur par défaut est de cinq minutes. Augmenter ce paramètre peut
accroitre le temps nécessaire à une récupération après un arrêt brutal.
Ce paramètre ne peut être configuré que dans le fichier
postgresql.conf
ou indiqué sur la ligne de commande.
checkpoint_completion_target
(floating point
) #
Précise la cible pour la fin du CHECKPOINT, sous le format d'une fraction
de temps entre deux CHECKPOINT. La valeur par défaut est 0,9, ce qui
répartit le checkpoint sur presque tout l'interval de temps entre deux
checkpoints, permettant ainsi d'absorber la charge d'écriture de manière
régulière tout en laissant un peu de temps pour absorber la charge
suppplémentaire induite par le checkpoint. Réduire la valeur de ce
paramètre n'est pas recommendé car cela engendrera des checkpoints se
finissant plus tôt, ce qui entraînera un pic dans les I/O alors que la
fin du checkpoint entraînera un creux dans les I/O entre la fin du
checkpoint courant et le début du prochain checkpoint. Ce paramètre ne
peut être configuré que dans le fichier
postgresql.conf
ou indiqué sur la ligne de
commande.
checkpoint_flush_after
(integer
)
#
Quand plus que cette quantité de données ont été
écrites par le processus d'écriture en tâche de fond (bgwriter), tente de
forcer le système d'exploitation à écrire les données sur disque. Faire
cela limite la quantité de données modifiées dans le cache disque du
noyau, réduisant le risque de petites pauses dues à l'exécution d'un
fsync à la fin d'un checkpoint ou à l'écriture massive en tâche de fond
des données modifiées. Souvent, cela réduira fortement la latence des
transactions mais il existe aussi quelques cas de dégradation des
performances, tout spécialement avec les charges de travail plus
importantes que shared_buffers, mais plus petites
que le cache disque du système d'exploitation. Ce paramètre pourrait ne
pas avoir d'effet sur certaines plateformes. Si cette valeur est indiquée
sans unité, elle est considérée comme un nombre de blocs, autrement dit
BLCKSZ
octets, typiquement 8 Ko. L'intervalle valide se situe
entre 0
, qui désactive le « writeback »
forcé, et 2MB
. La valeur par défaut est
256KB
sur Linux, 0
ailleurs. (Si
BLCKSZ
ne vaut pas 8 ko, les valeurs par défaut et
maximale n'évoluent pas de façon proportionnelle à cette constante.) Ce
paramètre est seulement configurable dans le fichier
postgresql.conf
et à 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 cette durée (ce qui laisse supposer qu'il faut augmenter la
valeur du paramètre max_wal_size
), un message
est écrit dans le fichier de traces du serveur.
Si cette valeur est indiquée sans unité, elle est considérée être un
nombre de secondes. Par défaut, 30 secondes.
Une valeur nulle (0) désactive cet avertissement.
Aucun avertissement ne sera fait si checkpoint_timeout
est inférieur à checkpoint_warning
.
Ce paramètre ne peut être configuré que dans le fichier
postgresql.conf
ou indiqué sur la ligne de commande.
max_wal_size
(integer
)
#
Taille maximale de l'augmentation des WAL entre deux points de vérification
automatique des WAL. C'est une limite souple ; la taille des WAL peut
excéder max_wal_size
sous certaines circonstances, comme
une surcharge du serveur, une commande archive_command
ou archive_library
qui échoue, ou une configuration
haute pour wal_keep_size
. Si cette valeur est indiquée
sans unité, elle est considérée être un nombre de Mo. La valeur par défaut
est 1 Go. Augmenter ce paramètre peut augmenter le temps nécessaire pour le
rejeu suite à un crash. Ce paramètre ne peut être configuré que dans le
fichier postgresql.conf
ou indiqué sur la ligne de
commande.
min_wal_size
(integer
)
#
Tant que l'occupation disque reste sous la valeur de ce paramètre, les
anciens fichiers WAL sont toujours recyclés pour une utilisation future
lors des points de vérification, plutôt que supprimés. Ceci peut être
utilisé pour s'assurer qu'un espace suffisant est réservé pour faire face
à des pics dans l'usage des WAL, par exemple lorsque d'importants travaux
en lots sont lancés. Si cette valeur est indiquée sans unité, elle est
considérée être un nombre de Mo. La valeur par défaut est 80 Mo. Ce
paramètre ne peut être configuré que dans le fichier
postgresql.conf
ou indiqué sur la ligne de commande.
archive_mode
(enum
) #
Quand archive_mode
est activé, les segments WAL remplis
peuvent être archivés en configurant archive_command
ou archive_library. En plus de
off
, pour désactiver, il y a deux autres modes :
on
, et always
. Lors du fonctionnement
normal du serveur, il n'y a pas de différences entre les deux modes, mais
lorsqu'il est positionné sur always
, l'archiveur des WAL
est aussi activé lors d'un rejeu des archives et en mode standby. Dans le
mode always
, tous les fichiers restaurés à partir de
l'archive ou envoyés lors de la réplication en continue seront archivés (à
nouveau). Voir Section 27.2.9 pour des
détails.
archive_mode
est un paramétrage séparé de
archive_command
et archive_library
pour que archive_command
et
archive_library
puissent être modifiés sans abandonner
le mode d'archivage. Ce paramètre ne peut être configuré qu'au lancement
du serveur. archive_mode
ne peut pas être activé quand
wal_level
est configuré à minimal
.
archive_command
(string
) #
Commande shell à exécuter pour archiver un segment terminé de
la série des fichiers WAL. 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. Il est important que la
commande renvoit un code zéro seulement si elle a réussit l'archivage.
Le processus d'archivage des journaux de transactions est redémarré par
le postmaster quand ce paramètre est modifié.
Pour plus d'informations, voir Section 26.3.1.
Ce paramètre ne peut être configuré que dans le fichier
postgresql.conf
ou indiqué sur la ligne de commande.
Il est uniquement utilisé si archive_mode
a été activé au
lancement du serveur et archive_library
est configuré à
une chaîne vide. If both
archive_command
and archive_library
are set, an error will be raised. Si archive_command
est une chaîne vide
(la valeur par défaut) alors que archive_mode
est activé
(et qu'archive_library
est configuré à une chaîne vide),
alors l'archivage des journaux de transactions est désactivé temporairement
mais le serveur continue d'accumuler les fichiers des journaux de
transactions dans l'espoir qu'une commande lui soit rapidement proposée.
Configurer archive_command
à une commande qui ne fait
rien tout en renvoyant true, par exemple /bin/true
(REM
sur Windows), désactive l'archivage mais casse
aussi la chaîne des fichiers des journaux de transactions nécessaires pour
la restauration d'une archive. Cela ne doit donc être utilisé quand lors de
circonstances inhabituelles.
archive_library
(string
)
#
Bibliothèque à utiliser pour l'archivage des journaux de transactions
terminés. Si configuré à une chaîne vide (valeur par défaut), l'archivage
via le shell est activé et archive_command est
utilisé. If both
archive_command
and archive_library
are set, an error will be raised. Sinon, la bibliothèque partagée est utilisée pour l'archivage.
Pour plus d'informations, voir Section 26.3.1 et
Chapitre 51.
Ce paramètre peut seulement être configuré dans le fichier
postgresql.conf
et sur la ligne de commande du
serveur.
archive_timeout
(integer
) #
Le archive_command ou le archive_library n'est appelé que pour les segments WAL
remplis. De ce fait, si le serveur n'engendre que peu de trafic WAL (ou
qu'il y a des périodes de plus faible activité), il se peut qu'un long
moment s'écoule entre la fin d'une transaction et son archivage certain.
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 cette durée s'est écoulée depuis le dernier changement de segment
et qu'il n'y a pas eu d'activité de la base de données, y compris un seul
CHECKPOINT. (les points de reprise sont ne sont pas effectués s'il n'y a
pas d'activité sur les bases.) 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. Cependant, vous devriez considérer
l'utilisation de la réplication en flux à la place de l'archivage si vous
voulez que les données soient envoyées du serveur primaire plus rapidement
que cela. Si cette valeur est indiquée sans unité, elle est considérée
comme un nombre de secondes. Ce paramètre ne peut être configuré que dans
le fichier postgresql.conf
ou indiqué sur la ligne de
commande.
Cette section décrit les paramètres s'appliquant à la restauration en général, affectant donc la restauration après un crash, la réplication en flux et la réplication à partir des archives.
recovery_prefetch
(enum
)
#
Indique s'il faut récupérer en avance
(prefetch) les blocs référencés dans le
journal de transaction qui ne sont pas encore dans le cache lors de la
restauration. Les valeurs valides sont off
,
on
et try
(la valeur par défaut). La
configuration try
active la récupération en avance
uniquement si le système d'exploitation fournit la fonction
posix_fadvise
, qui est actuellement utilisé pour
implémenter la récupération en avance. Notez que certains systèmes
d'exploitation fournissent la fonction mais elle ne fait rien.
Récupérer en avance les blocs qui seront bientôt nécessaires peut réduire les durées d'attente pour les opérations d'entrée/sortie disques lors de la restauration avec certains types de charge. Voir aussi les paramètres wal_decode_buffer_size et maintenance_io_concurrency, qui limitent l'activité de récupération en avance.
wal_decode_buffer_size
(integer
)
#Une limite sur l'avancée que peut avoir le serveur dans les WAL pour trouver les blocs à récupérer en avance. Si cette valeur n'a pas d'unité, elle sera considérée comme un nombre d'octets. La valeur par défaut est de 512 Ko.
Cette section décrit la configuration s'appliquant uniquement pendant la durée d'une restauration. Les paramètres doivent être reconfigurés pour toute restauration que vous souhaitez réaliser.
La « restauration » couvre l'utilisation d'un serveur en tant que standby ainsi que l'exécution d'une restauration ciblée. Typiquement, le mode standby sera utilisé pour fournir de la haute disponibilité et/ou de la répartition de charge en lecture, alors qu'une restauration ciblée sera utilisée dans le cas d'une perte de données.
Pour démarrer le serveur en mode standby, créez le fichier
standby.signal
dans le répertoire principal des données. Le serveur entrera en mode
restauration et n'arrêtera la restauration que quand la fin d'un WAL
archivé est rencontré, mais il essaiera de continuer la restauration en
se connectant au serveur d'envoi spécifié par le paramètre
primary_conninfo
et/ou en récupérant les segments WAL
avec la restore_command
. Pour ce mode, les paramètres
de cette section et de Section 20.6.3 sont intéressants. Les
paramètres de Section 20.5.6 seront
aussi appliqués mais ne sont généralement pas utiles dans ce mode.
Pour démarrer le serveur en mode restauration ciblée, créez le fichier
recovery.signal
dans le répertoire des données. Si les fichiers
standby.signal
et
recovery.signal
sont créés, le mode standby est
prioritaire. Le mode de restauration ciblée s'arrêtera quand le WAL
archivé est complètement rejoué ou quand
recovery_target
est atteint. Dans ce mode, les
paramètres de cette section et de Section 20.5.6 seront utilisés.
restore_command
(string
)
#
La commande shell locale à exécuter pour récupérer un segment WAL
archivé. Ce paramètre est requi pour une restauration d'archive, et
optionnel pour une réplication en streaming. Tout
%f
dans la chaîne est remplacé par le nom du
fichier à récupérer dans le répertoire d'archivage, et tout
%p
est remplacé par le nom du chemin destination de
la copie sur le serveur. (Le chemin est relatif au répertoire actuel,
donc le répertoire de données principal de l'instance.) Tout
%r
est remplacé par le nom du fichier contenant le
dernier point de redémarrage valide. C'est le fichier le plus récent à
conserver pour permettre le lancement d'une restauration, pour que
cette information puisse être utilisée pour tronquer l'archive au
minimum requis pour permettre le redémarrage de la restauration en
cours. %r
est généralement utilisé seulement pour
les configurations warm-standby (voir Section 27.2).
Écrire %%
pour ajouter un caractère
%
.
Il est important que la commande renvoie un code de sortie zéro uniquement en cas de succès. La commande doit gérer le fait que des fichiers ne soient pas présents dans les archives ; dans ce cas, elle doit renvoyer un code de sortie différent de zéro. Par exemple :
restore_command = 'cp /mnt/server/archivedir/%f "%p"' restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
Il existe une exception quand la commande est arrêtée avec un signal (autre que SIGTERM, qui est utilisé pour l'arrêt du serveur de bases de données) ou une erreur provenant du shell (par exemple « command not found »), alors la restauration s'arrêtera et le serveur ne démarrera pas.
Cette paramètre peut seulement être configuré au démarrage du serveur.
archive_cleanup_command
(string
)
#
Ce paramètre optionnel indique une commande shell exécutée à chaque
restartpoint. Le but de archive_cleanup_command
est
de fournir un mécanisme pour nettoyer les anciens fichiers WAL
archivés qui ne sont plus nécessaire sur le serveur standby. Tout
%r
est remplacé par le nom du fichier contenant le
dernier point de redémarrage valide. C'est le fichier le plus ancien à
conserver pour permettre une restauration, et
donc tous les fichiers plus ancien que %r
peuvent
être supprimés en toute sécurité. Cette information peut être utilisée
pour tronquer les archives au minimum requis pour supporter le
redémarrage à partir de la restauration en cours. Le module pg_archivecleanup est souvent utilisé dans
archive_cleanup_command
pour les configurations
avec un seul standby, par exemple ::
archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'
Notez néanmoins que si plusieurs serveurs standby exécutent leur
restauration à partir du même répertoire d'archivage, vous aurez
besoin de vous assurer que vous ne supprimez que des fichiers WAL dont
aucun serveur n'a besoin. archive_cleanup_command
serait typiquement utilisé dans une configuration warm-standby (voir
Section 27.2). Écrire %%
pour
intégrer un vrai caractère %
dans la commande.
Si la commande renvoie un code de sortie différent de zéro, alors un message d'avertissement sera écrit dans les traces. Une exception survient quand la commande est terminée par un signal ou une erreur du shell (tel que « command not found »), une erreur fatale sera renvoyée.
Ce paramètre peut seulement être configuré dans le fichier
postgresql.conf
ou sur la ligne de commande du
serveur.
recovery_end_command
(string
)
#
Ce paramètre indique une commande shell à exécuter une fois arrivé à
la fin de la restauration. Ce paramètre est optionnel. Le but de
recovery_end_command
est de fournir un mécanisme
pour nettoyer après une réplication ou une restauration. Tout
%r
est remplacé par le nom du fichier contenant le
dernier point de redémarrage valide, comme dans archive_cleanup_command.
Si la commande renvoie un code de sortie différent de zéro, alors un message d'avertissement sera écrit dans les traces et la base de données continuera à démarrer. Une exception survient si la commande a été terminée par un signal ou une erreur du shell (tel que « command not found »), la base de données ne continuera pas avec le démarrage.
Ce paramètre peut seulement être configuré dans le fichier
postgresql.conf
ou sur la ligne de commande du
serveur.
Par défaut, la restauration continuera jusqu'à la fin des WAL. Les
paramètres suivants peuvent être utilisés pour indiquer un point d'arrêt
précédent. Au moins un des paramètres parmi
recovery_target
,
recovery_target_lsn
,
recovery_target_name
,
recovery_target_time
et
recovery_target_xid
peut être utilisé. Si plus d'un
paramètre est indiqué dans le fichier de configuration, une erreur sera
renvoyée. Ces paramètres ne peuvent être configurés qu'au démarrage du
serveur.
recovery_target
= 'immediate'
#Ce paramètre indique que la restauration doit s'arrêter dès qu'un point de cohérence est atteint, autrement dit le plus tôt possible. Lors de la restauration d'une sauvegarde, cela signifie le moment où la sauvegarde s'est terminée.
Techniquement, la valeur est une chaîne de caractère, mais
'immediate'
est actuellement la seule valeur
autorisée.
recovery_target_name
(string
)
#
Ce paramètre indique le point de restauration nommé (créé précédemment
avec pg_create_restore_point()
) où la
restauration doit s'arrêter.
recovery_target_time
(timestamp
)
#Ce paramètre indique jusqu'à quel date et heure la restauration doit s'arrêter. Le point d'arrêt précis est aussi influencé par recovery_target_inclusive.
recovery_target_xid
(string
)
#Ce paramètre indique l'identifiant de transaction final où la restauration s'arrêtera. Gardez en tête que, bien que les identifiants soient affectés séquentiellement au début de la transaction, la transaction peut se terminer dans un ordre numérique différent. Les transactions qui seront restaurées sont celles validées avant (et en option en incluant) celle indiquée. Le point d'arrêt précis est aussi influencé par recovery_target_inclusive.
La valeur de ce paramètre est un horodatage dans le même format que
celui accepté par le type de données timestamp with time
zone
, à l'exception que vous ne pouvez pas utiliser une
abréviation de fuseau horaire (sauf si le paramètre timezone_abbreviations a été configuré précédemment
dans le fichier de configuration). Le style préféré est d'utiliser un
décalage numérique à partir d'UTC. Vous pouvez aussi écrire un nom
complet de fuseau horaire, par exemple
Europe/Helsinki
, et non pas
EEST
.
recovery_target_lsn
(pg_lsn
)
#
Ce paramètre indique le LSN où la restauration s'arrêtera. Le point
d'arrêt précis est aussi influencé par recovery_target_inclusive. Ce paramètre est analysé en
utilisant le type de données système pg_lsn
.
Les options suivants indiquent plus en détails la cible de restauration, et affectent ce qui survient quand la cible est atteinte :
recovery_target_inclusive
(boolean
)
#
Indique s'il faut arrêter juste après la cible de restauration
indiquée (on
) ou juste avant
(off
). S'applique quand recovery_target_lsn, recovery_target_time ou recovery_target_xid est spécifié. Ce paramètre
contrôle si les transactions ayant exactement, respectivement, le même
emplacement WAL (LSN), heure de validation, ou identifiant de
transaction seront incluses dans la restauration. La valeur par défaut
est on
.
recovery_target_timeline
(string
)
#
Indique la restauration jusqu'à une certaine timeline. La valeur peut
être un identifiant numérique de timeline. La valeur
current
restaure uniquement sur la même timeline
que celle de la sauvegarde de base. La valeur
latest
restaure jusqu'à la dernière timeline
trouvée dans les archives, ce qui est utile pour un serveur standby.
latest
est la valeur par défaut.
Pour spécifier un identifiant de timeline en hexadécimal
(par exemple, si extraite du nom d'un fichier WAL ou du fichier
d'historique), il est nécessaire de préfixer la valeur par
0x
. Par exemple, si le nom du fichier WAL est
00000011000000A10000004F
, alors l'identifiant est
0x11
(ou 17 en décimal).
Vous avez seulement besoin de configurer ce paramètre dans les situations complexes de re-restaurations, où vous avez besoin de retourner à un état qui a été lui-même atteint après une restauration à un point dans le temps. Voir Section 26.3.5 pour plus de détails.
recovery_target_action
(enum
)
#
Indique l'action que le serveur devra prendre une fois la cible de
restauration atteinte. La valeur par défaut est
pause
, ce qui signifie que la restauration sera
mise en pause. promote
signifie que le processus de
restauration finira et que le serveur démarrera pour accepter toute
connexion. Enfin, shutdown
arrêtera le serveur
après avoir atteint la cible de restauration.
Le but de la configuration pause
est de permettre
d'exécuter des requêtes sur la base pour vérifier si la cible de
restauration est le point réellement souhaité pour la fin de la
restauration. La mise en pause peut être annulée en utilisant
pg_wal_replay_resume()
(voir Tableau 9.93), qui cause ainsi la fin
de la restauration. Si la cible de restauration n'est pas le point
d'arrêt souhaité, alors arrêtez le serveur, modifiez la configuration
de la cible de restauration à un point ultérieur et redémarrer pour
continuer la restauration.
La configuration shutdown
est utile pour avoir
l'instance prête au point de rejeu exact désiré. L'instance sera
toujours capable de rejouer plus d'enregistrements WAL (et en fait,
continuera à rejouer des enregistrements WAL depuis le dernier
checkpoint à son redémarrage).
Notez que comme recovery.signal
ne sera pas
supprimé quand recovery_target_action
est configuré
à shutdown
, tout redémarrage finira avec un arrêt
immédiat à moins que la configuration ait changé ou que le fichier
recovery.signal
ait été supprimé manuellement.
Cette configuration n'a pas d'effet si aucune cible de restauration
n'a été configurée. Si hot_standby n'est pas
activé, une configuration à pause
agira de la même
façon qu'une configuration à shutdown
.
Si la cible de restauration est atteinte alors qu'une promotion est en
cours, une configuration à pause
agira de la même
façon qu'une configuration à promote
.
Dans tous les cas, si une cible de restauration est configurée mais que la restauration d'archive se termine avant d'avoir atteint la cible, le serveur s'arrêtera avec une erreur fatale.