18.6. Réplication

Indique le nombre maximum de connexions concurrentes à partir des 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. Ce paramètre peut seulement être configuré au lancement du serveur. wal_level doit être configuré à archive ou hot_standby pour permettre les connexions des serveurs en attente.

Précise le délai entre deux tours d'activité des processus walsender. À chaque tour, le processus walsender envoie tous les enregistrements WAL accumulés depuis sont dernier tour. Il s'endort ensuite pour wal_sender_delay millisecondes et recommence. L'attente est interrompue par une validation de transaction, donc les effets d'une transaction validée sont envoyés aux serveurs en attente dès que la validation survient, quelque soit la configuration de ce paramètre. La valeur par défaut est de une seconde (1s). Notez que sur de nombreux systèmes la résolution réelle du délai d'endormissement en de 10 millisecondes ; configurer wal_sender_delay à une valeur qui n'est pas un multiple de 10 pourrait avoir le même résultat que de le configurer à la valeur suivante multiple de 10. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande 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 primaire pour plus de wal_keep_segments fichiers, le primaire pourrait supprimer un journal de transactions toujours utile au serveur en attente, auquel cas la connexion de réplication serait fermée. (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 n'a aucun effet sur les restartpoints. 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 pendant lesquelles les VACUUM et les mises à jour HOT reporteront à plus tard le nettoyage des versions de lignes mortes. La valeur par défaut est de zéro transaction. Cela veut dire que les versions de lignes mortes peuvent être supprimées dès que possible, autrement dit à partir du moment où elles ne sont plus visibles par les transactions en cours d'exécution. Vous pourriez augmenter la valeur de ce paramètre sur un serveur maître qui accepte des serveurs en attente de type hotstandby, comme décrit dans Section 25.5, « Hot Standby ». Ceci donne plus de temps aux requêtes sur les serveurs hotstandby pour qu'elles se terminent avec succès, sans conflit relatif à un nettoyage des lignes. Néanmoins, comme la valeur est mesurée en terme de nombres de transactions en écriture survenant sur le serveur maître, il est difficile de prédire le temps supplémentaire que cela met à disposition des requêtes sur les serveurs hotstandby. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Pensez à configurer hot_standby_feedback comme alternative à ce paramètre.

Termine les connexions de réplication inactives depuis au moins ce nombre de millisecondes. C'est utile pour que le serveur maître 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.

Pour empêcher l'arrêt prématuré des connexions, wal_receiver_status_interval doit être activé sur le serveur en standby et sa valeur doit être inférieur à la valeur de replication_timeout.

Précise une liste de noms de serveur en standby, chacun séparé par une virgule, acceptant une réplication synchrone, comme décrite dans Section 25.2.6, « Réplication synchrone ». À tout moment, il y aura au maximum un serveur standby synchrone actif ; les transactions en attente de validation seront autorisées à continuer après que le serveur standby aura confirmé la réception des données. Le standby synchrone est le premier serveur standby nommé dans cette liste, qui est à la fois connecté et qui récupère 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 le serveur standby synchrone se déconnecte, 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é.

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 choisi pour être le serveur standby synchrone 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.

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 si vous pouvez vous connecter et exécuter des requêtes lors de la restauration, comme indiqué dans Section 25.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 25.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 25.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 principal, 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.

Quand replication_timeout est activé sur le serveur principal, wal_receiver_status_interval doit être activé et sa valeur doit être inférieure à la valeur de replication_timeout.

Spécifie si un serveur en Hot Standby enverra des informations au serveur principal 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.