Indique le nombre maximum de serveurs standby (autrement dit, le nombre maximum de processus walsender en cours d'exécution). La valeur par défaut est 10. La valeur 0 signifie que la réplication est désactivée. Une déconnexion abrute d'un client de réplication pourrait avoir pour effet un slot de connexion orpheline jusqu'au dépassement d'un délai, donc ce paramètre peut être configuré un peu au-dessus du nombre maximum de clients attendus pour que les clients déconnectés puissent immédiatement se reconnecter. Ce paramètre n'est configurable qu'au démarrage du serveur. wal_level doit être configuré au minimum à replica pour permettre des connexions des serveurs esclaves.

Lors de l'exécution d'un serveur standby, vous devez configurer ce paramètre à la même valeur ou à une valeur supérieure à celle se trouvant sur le serveur d'envoi. Dans le cas contraire, les requêtes ne seront pas autorisées sur le serveur standby.

Indique le nombre maximum de slots de réplication (voir Section 26.2.6) que le serveur peut accepter. La valeur par défaut est 10. Ce paramètre est seulement configurable au lancement du serveur. Descendre ce paramètre à une valeur inférieure au nombre de slots de réplication existants empêchera le serveur de démarrer. wal_level doit aussi être positionné à replica ou au-delà pour permettre l'utilisation des slots de réplication.

Du côté du souscripteur, indique le nombre d'origines de réplication (voir Chapitre 49) pouvant être tracées simultanément, limitant directement le nombre de souscriptions de réplication logique pouvant être créées sur le serveur. Le configurer à une valeur plus basse que le nombre actuel d'origines de réplication tracées (telle qu'indiquée dans pg_replication_origin_status, et non pas pg_replication_origin) empêchera le démarrage du serveur.

Indique le nombre minimum de journaux de transactions passés à conserver dans le répertoire pg_wal, au cas où un serveur en attente a besoin de les récupérer pour la réplication en flux. Chaque fichier fait normalement 16 Mo. Si un serveur en attente connecté au primaire se laisse distancer par le serveur en envoi pour plus de wal_keep_segments fichiers, le serveur en envoi pourrait supprimer un journal de transactions toujours utile au serveur en attente, auquel cas la connexion de réplication serait fermée. Les connexions en aval seront également vouées à l'échec. (Néanmoins, le serveur en attente peut continuer la restauration en récupérant le segment des archives si l'archivage des journaux de transactions est utilisé.)

Cette option ne configure que le nombre minimum de fichiers à conserver dans pg_wal ; le système pourrait avoir besoin de conserver plus de fichiers pour l'archivage ou pour restaurer à partir d'un CHECKPOINT. Si wal_keep_segments vaut zéro (ce qui est la valeur par défaut), le système ne conserve aucun fichier supplémentaire pour les serveurs en attente et le nombre des anciens journaux disponibles pour les serveurs en attente est seulement basé sur l'emplacement du dernier CHECKPOINT ainsi que sur l'état de l'archivage des journaux de transactions. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Termine les connexions de réplication qui sont inactives pour plus longtemps que cette durée. Ceci est utile pour que le serveur d'envoi détecte le crash d'un standby ou une perte réseau. Si cette valeur est spécifiée sans unité, elle est comprise comme un nombre de millisecondes. La valeur par défaut est de 60 secondes. À zéro, le mécanisme est désactivé.

Avec un cluster distribué sur plusieurs lieux géographiques, utiliser plusieurs valeurs par lieu fournit plus de flexibilité dans la gestion du cluster. Une valeur plus petite est utile pour une détection plus rapide des problèmes avec un standby ayant un réseau à basse latence. Une valeur plus haute aide à mieux juger la santé d'un standby si ce dernier est situé sur un lieu distant, avec une connexion réseau à haute latence.

Enregistre la date et l'heure des transactions validées. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur. La valeur par défaut est off.

Précise une liste de noms de serveurs en standby acceptant une réplication synchrone, comme décrite dans Section 26.2.8. À tout moment, il y aura au moins un serveur standby synchrone actif ; les transactions en attente de validation seront autorisées à continuer après que les serveurs standbys synchrones auront confirmé la réception des données. Les standbys synchrones sont les serveurs standbys nommés dans cette liste, qui sont à la fois connectés et qui récupèrent les données en temps réel (comme indiqué par l'état streaming dans la vue pg_stat_replication). Indiquer plus d'un serveur standby synchrone permet une meilleure haute- disponibilité et une meilleure protection contre les pertes de données.

Le nom d'un serveur standby est indiqué dans ce cas au niveau du paramètre application_name du standby, tel qu'il est configuré dans l'information de connexion du standby. Dans le cas d'un standby en réplication physique, ceci doit être configuré dans le paramètre primary_conninfo. La valeur par défaut est la configuration de cluster_name si configuré, et sinon walreceiver. Pour la réplication logique, cela peut se configurer dans l'information de connexion de la souscription, et vaut par défaut le nom de la souscription. Pour les autres consommateurs de flux de réplication, veuillez consulter leur documentation.

Ce paramètre indique une liste de serveurs standbys en utilisant une des deux syntaxes suivantes :

[FIRST] nb_sync ( nom_standby [, ...] )
ANY nb_sync ( nom_standby [, ...] )
nom_standby [, ...]
     

où num_sync est le nombre de standbys synchrones dont les transactions doivent attendre des réponses, et nom_standby est le nom d'un serveur secondaire (standby). FIRST et ANY spécifie la méthode pour choisir les serveurs secondaires synchrones dans la liste des serveurs.

Le mot-clé FIRST, utilisé avec num_sync, spécifie une réplication synchrone basée sur la priorité, si bien que chaque validation de transaction attendra jusqu'à ce que les enregistrements des WAL soient répliqués de manière synchrone sur num_sync serveurs secondaires, choisis en fonction de leur priorités. Par exemple, utiliser la valeur FIRST 3 (s1, s2, s3, s4) forcera chaque commit à attendre la réponse de trois serveurs secondaires de plus haute priorité choisis parmis les serveurs secondaires s1, s2, s3 et s4. Les noms de serveurs secondaires qui apparaissent avant dans la liste reçoivent des priorités plus importantes et seront pris en considération pour être synchrones. Les autres serveurs secondaires apparaissant plus loin dans cette liste représentent les serveurs secondaire potentiellement synchrones. Si l'un des serveurs secondaires actuellement synchrones se déconnecte pour quelque raison que ce soit, il sera remplacé par le serveur secondaire de priorité la plus proche. Le mot clé FIRST est facultatif.

Le mot-clé ANY, utilisé avec num_sync, spécifie une réplication synchrone basée sur un quorum, si bien que chaque validation de transaction attendra jusqu'à ce que les enregistrements des WAL soient répliqués de manière synchrone sur au moins num_sync des serveurs secondaires listés. Par exemple, utiliser la valeur ANY 3 (s1, s2, s3, s4) ne bloquera chaque commit que le temps qu'au moins trois des serveurs de la liste s1, s2, s3 and s4 aient répondu, quels qu'ils soient.

FIRST et ANY sont insensibles à la casse. Si ces mots-clés sont utilisés comme nom d'un serveur secondaire, le paramètre standby_name doit être entouré de guillemets doubles.

La troisième syntaxe était utilisée avant PostgreSQL version 9.6 est toujours supportée. Cela revient à la nouvelle syntaxe avec FIRST et num_sync égal à 1. Par exemple, FIRST 1 (s1, s2) et s1, s2 ont la même signification : soit s1 soit s2 est choisit comme serveur secondaire synchrone.

L'entrée spéciale * correspond à tout nom de standby.

Il n'existe pas de mécanisme pour forcer l'unicité des noms de standby. Dans le cas de noms en double, un des standbys concernés sera considéré d'une priorité plus haute mais il n'est pas possible de prévoir lequel.

Si aucun nom de serveur en standby synchrone n'est indiqué ici, alors la réplication synchrone n'est pas activée et la validation des transactions n'attendra jamais la réplication. Ceci est la configuration par défaut. Même si la réplication synchrone est activée, les transactions individuelles peuvent être configurées pour ne pas avoir à attendre la réplication en configurant le paramètre synchronous_commit à local ou off.

Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Indique le nombre de transactions pour lesquelles VACUUM et les mises à jour HOT vont différer le nettoyage des versions de lignes mortes. La valeur par défaut est de 0 transactions. Cela signifie que les versions de lignes mortes peuvent être supprimées dès que possible, autrement dit dès qu'elles ne sont plus visibles par les transactions ouvertes. Vous pouvez configurer ce paramètre à une valeur supérieure à 0 sur un serveur primaire qui dispose de serveurs en Hot Standby comme décrit dans Section 26.5. Ceci donne plus de temps aux requêtes des serveur en standby pour qu'elles se terminent sans engendrer de conflits dû à un nettoyage rapide des lignes. Néanmoins, comme la valeur correspond à un nombre de transactions en écriture survenant sur le serveur primaire, il est difficile de prédire le temps additionnel que cela donne aux requêtes exécutées sur le serveur en standby. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Vous pouvez aussi configurer hot_standby_feedback sur les serveurs standby à la place de ce paramètre.

Ceci n'empêche pas le nettoyage des lignes mortes qui ont atteint l'âge spécifié par old_snapshot_threshold.

Indique une chaîne de connexion à utiliser pour la connexion du serveur standby vers le serveur primaire. Cette chaîne doit être dans le format décrit dans Section 33.1.1. Si une option n'est pas spécifiée dans cette chaîne, alors la variable d'environnement correspondante (voir Section 33.14) est vérifiée. Si la variable d'environnement n'est pas configurée, la valeur par défaut est utilisée.

La chaîne de connexion doit indiquer le nom d'hôte (ou l'adresse) du serveur d'envoi, ainsi que le numéro de port s'il ne s'agit pas du même numéro de port que la valeur par défaut du serveur standby. De plus, indiquez un nom d'utilisateur correspondant à un rôle suffisamment privilégié du serveur d'envoi (voir Section 26.2.5.1). Un mot de passe doit aussi être fourni si le serveur d'envoi réclame une authentification par mot de passe. Il peut être indiqué dans la chaîne primary_conninfo ou dans un fichier ~/.pgpass sur le serveur standby (utiliser replication comme nom de base). N'indiquez pas de nom de base dans la chaîne primary_conninfo.

Ce paramètre peut seulement être configuré au démarrage du serveur. Il n'a pas d'effet si le serveur n'est pas en mode standby.

Indique en option un slot de réplication existant à utiliser lors de la connexion au serveur d'envoi via la réplication en flux pour contrôler la suppression des journaux du serveur d'envoi (voir Section 26.2.6). Ce paramètre peut seulement être configuré au démarrage du serveur. Il n'a aucun effet si primary_conninfo n'est pas configuré.

Indique un fichier trigger dont la présence termine la restauration sur le serveur secondaire. Même si cette valeur n'est pas configurée, vous pouvez toujours promouvoir le standby en utilisant pg_ctl promote ou en appelant pg_promote. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Indique si vous pouvez vous connecter et exécuter des requêtes lors de la restauration, comme indiqué dans Section 26.5. Activé par défaut. Ce paramètre peut seulement être configuré au lancement du serveur. Il a un effet seulement lors de la restauration des archives ou en mode serveur en attente.

Quand le Hot Standby est activé, ce paramètre détermine le temps maximum d'attente que le serveur esclave doit observer avant d'annuler les requêtes en lecture qui entreraient en conflit avec des enregistrements des journaux de transactions à appliquer, comme c'est décrit dans Section 26.5.2. max_standby_archive_delay est utilisé quand les données de journaux de transactions sont lues à partir des archives de journaux de transactions (et du coup accuse un certain retard par rapport au serveur maître). Si cette valeur est indiquée sans unité, elle est comprise comme un nombre de millisecondes. La valeur par défaut est de 30 secondes. L'unité est la milliseconde si cette dernière n'est pas spécifiée. Une valeur de -1 autorise le serveur en attente à attendre indéfiniment la fin d'exécution des requêtes en conflit. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Notez que max_standby_archive_delay ne correspond pas au temps d'exécution maximum d'une requête avant son annulation ; il s'agit plutôt du temps maximum autorisé pour enregistrer les données d'un journal de transactions. Donc, si une requête a occasionné un délai significatif au début du traitement d'un journal de transactions, les requêtes suivantes auront un délai beaucoup moins important.

Quand Hot Standby est activé, ce paramètre détermine le délai maximum d'attente que le serveur esclave doit observer avant d'annuler les requêtes en lecture qui entreraient en conflit avec les enregistrements de transactions à appliquer, comme c'est décrit dans Section 26.5.2. max_standby_streaming_delay est utilisé quand les données des journaux de données sont reçues via la connexion de la réplication en flux. Si cette valeur est indiquée sans unité, elle est comprise comme un nombre de millisecondes. La valeur par défaut est de 30 secondes. L'unité est la milliseconde si cette dernière n'est pas spécifiée. Une valeur de -1 autorise le serveur en attente à attendre indéfiniment la fin d'exécution des requêtes en conflit. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Notez que max_standby_streaming_delay ne correspond pas au temps d'exécution maximum d'une requête avant son annulation ; il s'agit plutôt du temps maximum autorisé pour enregistrer les données d'un journal de transactions une fois qu'elles ont été récupérées du serveur maître. Donc, si une requête a occasionné un délai significatif au début du traitement d'un journal de transactions, les requêtes suivantes auront un délai beaucoup moins important.

Indique la fréquence minimale pour que le processus de réception (walreceiver) sur le serveur de standby envoie des informations sur la progression de la réplication au serveur en envoi, où elles sont disponibles en utilisant la vue pg_stat_replication. Le serveur en standby renvoie la dernière position écrite dans le journal de transactions, la dernière position vidée sur disque du journal de transactions, et la dernière position rejouée. La valeur de ce paramètre est la durée maximale entre les rapports. Les mises à jour sont envoyées à chaque fois que les positions d'écriture ou de vidage ont changées et de toute façon au moins aussi fréquemment que l'indique ce paramètre. Du coup, la position de rejeu pourrait avoir un certain retard par rapport à la vraie position. Si cette valeur est indiquée sans unité, elle est considérée en secondes. La valeur par défaut est de 10 secondes. Configurer ce paramètre à zéro désactive totalement les mises à jour de statut. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Spécifie si un serveur en Hot Standby enverra des informations au serveur en envoi sur les requêtes en cours d'exécution sur le serveur en standby. Ce paramètre peut être utilisé pour éliminer les annulations de requêtes nécessaires au nettoyage des enregistrements. Par contre, il peut causer une fragmentation plus importante sur le serveur principal pour certaines charges. Les messages d'informations ne seront pas envoyés plus fréquemment qu'une fois par wal_receiver_status_interval. La valeur par défaut est off. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Si la réplication en cascade est utilisée, les informations sont passées à l'émetteur jusqu'à arriver au serveur primaire. Les serveurs en standby ne font aucun usage des informations qu'ils reçoivent, en dehors de les envoyer à leur émetteur des données de réplication.

Ce paramètre ne surcharge pas le comportement de old_snapshot_threshold sur le primaire ; une image de la base sur le standby qui dépasse la limite d'âge du primaire peut devenir invalide, résultant en une annulation des transactions sur le standby. Ceci a pour explication que old_snapshot_threshold a pour but de fournir une limite absolue sur la durée où des lignes mortes peuvent contribuer à la fragmentation, qui, dans le cas contraire, pourrait être transgressé à cause de la configuration du standby.

Termine les connexions de réplication qui sont inactives pour plus longtemps que cette durée. Ceci est utile pour que le serveur de réception détecte le crash d'un serveur primaire ou une perte réseau. Si cette valeur est spécifiée sans unité, elle est comprise comme un nombre de millisecondes. La valeur par défaut est de 60 secondes. À zéro, le mécanisme est désactivé. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou en ligne de commande.

Indique combien de temps le serveur standby doit attendre lorsque les données des WAL ne sont pas disponibles auprès des sources habituelles (réplication en continu, localement à partir de pg_wal ou de l'archivage des WAL) avant d'essayer à nouveau de récupérer les WAL. Si cette valeur est spécifiée sans unité, elle est comprise comme un nombre de millisecondes. La valeur par défaut est de 5 secondes. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Ce paramètre est utile dans les configurations où un nœud en cours de restauration a besoin de contrôler le temps à attendre pour la disponibilité de nouveaux WAL. Par exemple, en mode restauration à partir des archives, il est possible d'avoir une restauration plus réactive dans la détection d'un nouveau fichier WAL en réduisant la valeur de ce paramètre. Sur un système avec une génération faible de WAL, l'augmenter réduit le nombre de requêtes nécessaires pour accèder aux WAL archivés, quelque chose utile par exemple dans les environnements cloud où le nombre de fois où l'infrastructure est accédée est pris en compte.

Par défaut, un serveur standby restaure les enregistrements des WAL du serveur d'envoi dès que possible. Il peut être utile d'avoir une copie qui appliquer les données de réplication avec un délai spécifié pour prévenir en cas de perte de données. Ce paramètre vous permet de repousser l'application de la restauration sur une période de temps fixée. Par exemple, si vous configurez ce paramètre à 5min, le standby ne rejouera chaque validation de transaction seulement quand l'heure système sur le standby est au moins cinq minutes après l'heure de validation rapportée par le primaire. Si cette valeur est spécifiée sans unité, elle est comprise comme un nombre de millisecondes. La valeur par défaut est zéro, pour ne pas ajouter de délai.

Il est possible que le délai de réplication entre les serveurs dépasse la valeur de ce paramètre, auquel cas aucun délai n'est ajouté. Notez que le délai est calculé entre l'horodatage du WAL écrit sur le primaire et l'heure système actuel sur le secondaire. Les délais dans le transfert, à cause d'un retard réseau ou de configuration de réplication en cascade, pourraient réduire le temps d'attente de façon importante. Si les horloges systèmes du primaire et du secondaire ne sont pas synchronisées, ceci pourrait amener la restauration à appliquer des enregistrements plus rapidement que souhaité. Ceci n'est pas un problème important parce que la configuration intéressante de ce paramètre est bien plus importante que les déviations habituelles d'horloge entre serveurs.

Le délai n'est appliqué que sur les enregistrements WAL des validations de transaction. Les autres enregistrements sont rejoués aussi rapidement que possible, ce qui n'est pas un problème vu que les règles de visibilité avec MVCC nous assurent que les effets ne sont pas visibles tant que l'enregistrement de validation correspondant n'est pas appliqué.

Le délai survient une fois que la base de données en restauration a atteint un point de cohérence, et jusqu'à ce que le standby soit promu. Après cela, le standby arrêtera toute restauration et sans délai.

Ce paramètre vise les déploiements de réplication par flux. Néanmoins, la configuration de ce paramètre sera honorée dans tous les cas, sauf dans le cas de la restauration après un crash. hot_standby_feedback se verra imposé le délai, ce qui peut amener de la fragmentation sur le serveur primaire. N'activez les deux qu'avec précaution.

Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Spécifie le nombre maximal de workers de réplication logique. Cela inclue à la fois les workers ainsi que les workers de synchronisation de table.

Les workers de réplication logique sont pris de la réserve définie par max_worker_processes.

La valeur par défaut est 4. Ce paramètre peut seulement être configuré au démarrage du serveur.

Le nombre maximal de workers de synchronisation par souscription. Ce paramètre contrôle la quantité de parallélisme pour la copie initiale de données durant l'initialisation de la souscription ou quand de nouvelles tables sont ajoutées.

Pour le moment, il ne peut y avoir qu'un seul worker de synchronisation par table.

Les workers de synchronisation sont pris de la réserve définie par max_logical_replication_workers.

La valeur par défaut est 2. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.