27.3. Paramètres de serveur de Standby

Spécifie s'il faut démarrer le serveur PostgreSQL™ en tant que standby. Si ce paramètre est à on, le serveur n'arrête pas la récupération quand la fin du WAL archivé est atteinte, mais continue d'essayer de poursuivre la récupération en récupérant de nouveaux segments en utilisant restore_command et/ou en se connectant au serveur primaire comme spécifié par le paramètre primary_conninfo.

Spécifie au serveur de standby la chaîne de connexion à utiliser pour atteindre le primaire. Cette chaîne est dans le format décrie dans Section 32.1.1, « Chaînes de connexion ». Si une option n'est pas spécifiée dans cette chaîne, alors la variable d'environnement correspondante (voir Section 32.14, « Variables d'environnement ») est examinée. Si la variable d'environnement n'est pas positionnée non plus, la valeur par défaut est utilisée.

La chaîne de connexion devra spécifier le nom d'hôte (ou adresse) du serveur primaire, ainsi que le numéro de port si ce n'est pas le même que celui par défaut du serveur de standby. Spécifiez aussi un nom d'utilisateur disposant des droits adéquats sur le primaire (voir Section 26.2.5.1, « Authentification »). Un mot de passe devra aussi être fourni, si le primaire demande une authentification par mot de passe. Il peut être fourni soit dans la chaîne primary_conninfo soit séparément dans un fichier ~/.pgpass sur le serveur de standby (utilisez replication comme nom de base de données). Ne spécifiez pas de nom de base dans la chaîneprimary_conninfo

Ce paramètre n'a aucun effet si standby_mode vaut off.

Indique en option un slot de réplication existant à utiliser lors de la connexion au serveur principal via la réplication en vue, dans le but de contrôler la suppression des ressources sur le serveur principal (voir Section 26.2.6, « Slots de réplication »). Ce paramètre n'a aucun effet si le paramètre primary_conninfo n'est pas configuré.

Spécifie un fichier trigger dont la présence met fin à la récupération du standby. Même si cette valeur n'est pas configurée, vous pouvez toujours promouvoir le serveur en attente en utilisant pg_ctl promote. Ce paramètre n'a aucun effet si standby_mode vaut off.

Par défaut, un serveur standby restaure les enregistrements des journaux de transactions provenant du serveur primaire dès que possible. Dans certains cas, il peut se révéler utile d'avoir une copie des données dont la restauration accuse un certain retard programmé. Cela ouvre notamment différentes options pour corriger les erreurs de perte de données. Ce paramètre vous permet de retarder la restauration pr une période de temps fixe, spécifiée en millisecondes si aucune unité n'est spécifiée. Par exemple, si vous configurez ce paramètre à 5min, le serveur standby rejouera chaque transaction seulement quand l'horloge système de l'esclave dépasse de cinq minutes l'heure de validation rapportée par le serveur maître.

Il est possible que le délai de réplication entre 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 journal de transactions écrit sur le maître et la date et heure courante sur le standby. Les délais de transfert dûs aux réseaux et aux configurations de réplication en cascade peuvent réduire le temps d'attente réel de façon significative. Si les horloges systèmes du maître et de l'esclave ne sont pas synchronisés, cela peut amener à la restauration d'enregistrements avant le délai prévu ; mais ce n'est pas un problème grave car les valeurs intéressantes pour ce paramètre sont bien au dessus des déviations d'horloge typiques.

Le délai survient seulement sur les validations (COMMIT) des transactions. D'autres enregistrements sont rejoués aussi rapidement que possible, ce qui n'est pas un problème car les règles de visibilité MVCC nous assurent que leurs effets ne sont pas visibles jusqu'à l'application de l'enregistrement du COMMIT.

Le délai est observé une fois que la base de données en restauration a atteint un état cohérent jusqu'à ce que le serveur standby soit promu ou déclenché. Après cela, le serveur standby terminera la restauration sans attendre.

Ce paramètre cible principalement les déploiements de la réplication en flux. Cependant, si le paramètre est spécifié, il honorera tous les cas. hot_standby_feedback sera retardé par l'utilisation de cette fonctionnalité, qui peut aboutir à de la fragmentation sur le maître. Faites attention en utilisant les deux.

Avertissement

La réplication synchrone est affectée par ce paramètre quand synchronous_commit est configuré à remote_apply ; chaque COMMIT devra attendre son rejeu.