Ces paramètres contrôlent le comportement de la fonctionnalité interne de réplication en flux (voir Section 26.2.5, « Streaming Replication »). Les serveurs seront soit maître soit esclave. Les maîtres peuvent envoyer des données alors que les esclaves sont toujours des récepteurs des données de réplication. Quand la réplication en cascade est utilisée (voir Section 26.2.7, « Réplication en cascade »), les esclaves peuvent aussi envoyer des données en plus de les réceptionner. Les paramètres sont principalement pour les serveurs d'envoi et en standby, bien que certains n'ont un intérêt que pour le serveur maître. Les paramètres peuvent varier dans l'instance sans problèmes si cela est requis.
Ces paramètres peuvent être configurés sur les serveur qui va envoyer les données de réplication à un ou plusieurs serveurs. Le maître est toujours un serveur en envoi. Donc ces paramètres doivent être configurés sur le maître. Le rôle et la signification de ces paramètres ne changent pas après qu'un serveur standby soit devenu le serveur maître.
serveurs en attente (c'est-à-dire le nombre maximum de processus walsender en cours d'exécution). La valeur par défaut est zéro, signifiant que la réplication est désactivée. Les processus walsender sont lançables jusqu'à atteindre le nombre total de connexions, donc ce paramètre ne peut pas être supérieur à max_connections. 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.
Indique le nombre maximum de slots de réplication (voir Section 26.2.6, « Slots de réplication ») que le serveur peut accepter. La valeur par défaut est zéro. Ce paramètre est seulement configurable au lancement du serveur. Le paramètre wal_level doit être configuré à replica ou supérieur pour permettre l'utilisation des slots de réplication. Le configurer à une valeur plus petite que le nombre de slots de réplications déjà existants empêchera le démarrage du serveur.
Indique le nombre minimum de journaux de transactions passés à conserver dans le répertoire pg_xlog, 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é.)
Cela configure seulement le nombre minimum de fichiers à conserver dans pg_xlog ; 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 inactives depuis au moins ce nombre de millisecondes. C'est utile pour que le serveur en envoi détecte un arrêt brutal du serveur en standby ou un problème réseau. Une valeur de zéro désactive ce mécanisme. 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 de 60 secondes.
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.
Ces paramètres peuvent être configurés sur le serveur maître/primaire pour envoyer des données de réplication à un ou plusieurs serveurs en standby. Notez qu'en plus de ces paramètres, wal_level doit être configuré correctement sur le serveur maître et que l'archivage des journaux de transactions peut aussi être activé (voir Section 19.5.3, « Archivage »). Les valeurs de ces paramètres ne sont pas pris en compte sur les serveurs en standby. Il peut être intéressant de les mettre en place malgré tout en préparation de la possibilité qu'un standby devienne le maître.
Précise une liste de noms de serveurs en standby acceptant une réplication synchrone, comme décrite dans Section 26.2.8, « Réplication synchrone ». À 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 premiers 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). Les autres serveurs standards apparaissant plus tard dans cette liste sont des serveurs standbys synchrones potentiels. Si un des serveurs standbys synchrones se déconnectent, quel qu'en soit la raison, il sera immédiatement remplacé par le prochain standby dans l'ordre des priorités. Indiquer plus qu'un nom de standby peut augmenter fortement la haute disponibilité.
Ce paramètre indique une liste de serveurs standbys en utilisant une des deux syntaxes suivantes :
Write Ahead Log
num_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). Par exemple, une configuration à 3 (s1, s2, s3, s4) fait que les validations de transaction attendent que les enregistrements WAL soient reçu par les trois standbys de priorité haute choisis parmi les serveurs standbys s1, s2, s3 et s4.
La deuxième syntaxe était utilisée avant PostgreSQL™ version 9.6 est est toujours supportée. Cela revient à la nouvelle syntaxe avec num_sync égal à 1. Par exemple, 1 (s1, s2) et s1, s2 ont la même signification : soit s1 soit s2 est choisi comme standby synchrone.
Dans ce cadre, le nom d'un serveur standby correspond au paramètre application_name du standby, qui est configurable dans primary_conninfo du walreceiver du standby. Il n'existe aucun paramètre pour s'assurer de l'unicité. Dans le cas où des serveurs ont le même nom, un des serveurs standby sera considéré de plus haute priorité mais il est impossible de déterminer lequel sera choisi. L'entrée spéciale * correspond à tout application_name, cela incluant le nom de l'application par défaut de walreceiver.
![[Note]](../images/note.png)
Chaque nom_standby doit avoir la forme d'un identifiant SQL valide, sauf si * est utilisé. Vous pouvez utiliser des guillemets doubles si nécessaire mais notez que les nom_standby sont comparés au nom d'application des standbys sans faire attention à la casse, qu'ils aient des guillemets doubles ou non.
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, « Hot Standby ». 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.
Ces paramètres contrôlent le comportement d'un serveur en attente pour qu'il puisse recevoir les données de réplication. Leur configuration sur le serveur maître n'a aucune importance.
Indique si vous pouvez vous connecter et exécuter des requêtes lors de la restauration, comme indiqué dans Section 26.5, « Hot Standby ». Désactivé 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, « Gestion des conflits avec les requêtes ». 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). 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, « Gestion des conflits avec les requêtes ». 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. 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 l'intervalle maximum, en secondes, 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. Configurer ce paramètre à zéro désactive complètement 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. La valeur par défaut est de dix secondes.
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 inactives depuis cette durée spécifiée en millisecondes. Ceci est utile pour que le serveur standby en réception détecte l'arrêt brutal d'un nœud primaire ou une coupure réseau. 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 de 60 secondes.
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_xlog ou de l'archivage des WAL) avant d'essayer à nouveau de récupérer les WAL. 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 de 5 secondes. Les unités sont en millisecondes si elles ne sont pas indiquées.
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.