Ces paramètres contrôlent le comportement de la fonctionnalité interne de réplication en flux (voir Section 27.2.5), et le mécanisme intégré de réplication logique (voir Chapitre 31).
Pour la réplication en flux, les serveurs seront soit primaire soit secondaire. Les primaires peuvent envoyer des données alors que les secondaires sont toujours des récepteurs des données de réplication. Quand la réplication en cascade est utilisée (voir Section 27.2.7), les secondaires 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 primaire. Les paramètres peuvent varier dans l'instance sans problèmes si cela est requis.
Pour la réplication logique, les serveurs publieurs
(serveurs qui exécutent CREATE PUBLICATION
)
répliquent les données vers les abonnés
(serveurs qui exécutent CREATE SUBSCRIPTION
).
Les serveurs peuvent également être publieur et abonné en même temps.
Les sections suivantes font référence aux publieurs comme émetteurs. Plus
de détails concernant les paramètres de configuration de la réplication logique
sur la page dédiée Section 31.10.
Ces paramètres peuvent être configurés sur les serveur qui va envoyer les données de réplication à un ou plusieurs serveurs. Le primaire est toujours un serveur en envoi. Donc ces paramètres doivent être configurés sur le primaire. Le rôle et la signification de ces paramètres ne changent pas après qu'un serveur standby soit devenu le serveur primaire.
max_wal_senders
(integer
) #
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
secondaires.
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.
max_replication_slots
(integer
)
#
Indique le nombre maximum de slots de réplication (voir Section 27.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.
Notez que ce paramètre est également pris en compte par les abonnés, mais avec une signification différente.
wal_keep_size
(integer
) #
Indique la taille minimale 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.
Si un serveur en attente connecté
au primaire se laisse distancer par le serveur en envoi pour plus de
wal_keep_size
méga-octets, 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 la volumétrie minimale 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_size
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. Si cette valeur est configurée
sans unité, elle est prise comme des méga-octets. Ce paramètre peut
seulement être configuré dans le fichier
postgresql.conf
ou sur la ligne de commande du
serveur.
max_slot_wal_keep_size
(integer
)
#
Indique la taille maximale des journaux de transaction que les slots de réplication sont
autorisés à conserver dans le répertoire pg_wal
lors
d'un checkpoint. Si max_slot_wal_keep_size
vaut -1
(valeur par défaut), les slots de réplication contiennent une quantité
illimitée de fichiers de journaux de transactions. Si la valeur du
restart_lsn d'un slot de réplication est en retard de plus de ce nombre de
mégaoctets depuis le LSN actuel, le standby utilisant le slot pourrait ne
plus pouvoir continuer la réplication du fait de la suppression des fichiers
WAL requis. Vous pouvez avoir la disponibilité des journaux de transactions
pour les slots de réplication dans la vue pg_replication_slots. Si cette
valeur est indiquée sans unité, elle est prise pour des mégaoctets. Ce
paramètre peut seulement être configuré dans le fichier
postgresql.conf
ou sur la ligne de commande du serveur.
wal_sender_timeout
(integer
) #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.
track_commit_timestamp
(boolean
)
#
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 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 primaire et que l'archivage des journaux de transactions peut aussi être activé (voir Section 20.5.3). 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 secondaire devienne le primaire.
synchronous_standby_names
(string
) #
Précise une liste de noms de serveurs en standby acceptant une réplication
synchrone, comme décrite dans Section 27.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
[, ...] ) ANYnb_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.
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.
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 primaire n'a aucune importance.
primary_conninfo
(string
)
#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 34.1.1. Si une option n'est pas spécifiée dans cette chaîne, alors la variable d'environnement correspondante (voir Section 34.15) 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 27.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é dans le fichier
postgresql.conf
ou sur la ligne de commande du
serveur. Si ce paramètre est modifié alors que le processus walreceiver
est en cours d'exécution, le processus reçoit une demandé d'arrêt et sera
redémarré avec la nouvelle configuration (sauf si
primary_conninfo
est une chaîne vide). Il n'a pas
d'effet si le serveur n'est pas en mode standby.
primary_slot_name
(string
)
#
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 27.2.6). Ce paramètre peut seulement
être configuré dans le fichier postgresql.conf
ou
sur la ligne de commande du serveur. Si ce paramètre est modifié alors
que le processus walreceiver est en cours d'exécution, le processus
reçoit une demandé d'arrêt et sera redémarré avec la nouvelle
configuration (sauf si primary_conninfo
est une chaîne
vide). Il n'a pas d'effet si primary_conninfo
n'est
pas configuré ou si le serveur n'est pas en mode standby.
hot_standby
(boolean
) #Indique si vous pouvez vous connecter et exécuter des requêtes lors de la restauration, comme indiqué dans Section 27.4. 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.
max_standby_archive_delay
(integer
) #
Quand le Hot Standby est activé, ce paramètre détermine le temps
maximum d'attente que le serveur secondaire 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 27.4.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 primaire). 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.
max_standby_streaming_delay
(integer
) #
Quand Hot Standby est activé, ce paramètre détermine le délai maximum
d'attente que le serveur secondaire 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 27.4.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 primaire. 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.
wal_receiver_create_temp_slot
(boolean
)
#
Indique si le processus walreceiver doit créer un slot de réplication
temporaire sur l'instance distante lorsqu'aucun slot de réplication
permanent n'a été configuré (en utilisant primary_slot_name). 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 ce paramètre est modifié alors que le processus walreceiver
est en cours d'exécution, alors ce processus reçoit un signal pour
s'arrêter et utilisera le nouveau paramètre à son redémarrage.
wal_receiver_status_interval
(integer
) #
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
aussi fréquemment que l'indique ce paramètre s'il est configuré à une
valeur autre que zéro. Il existe aussi des cas ou les mises à jour sont
envoyées en ignorant ce paramètre. Par exemple, lorsque le traitement du
WAL courant se termine ou lorsque synchronous_commit
est configuré à remote_apply
. 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. Ce paramètre peut
seulement être configuré dans le fichier
postgresql.conf
ou sur la ligne de commande du
serveur.
hot_standby_feedback
(boolean
) #
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.
wal_receiver_timeout
(integer
) #
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.
wal_retrieve_retry_interval
(integer
)
#
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.
recovery_min_apply_delay
(integer
)
#
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.
Les enregistrements des journaux de transactions sont conservés sur le
serveur secondaire jusqu'à ce qu'ils soient prêts à être appliqués. De ce
fait, des délais plus importants peuvent résulter en une accumulation plus
importante de journaux de transactions, augmentant ainsi les besoins en
espace disque du répertoire pg_wal
sur le secondaire.
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.
La réplication synchrone est affectée par ce paramétrage quand
synchronous_commit
est configuré à
remote_apply
; chaque COMMIT
aura besoin d'attendre son application.
Ce paramètre peut seulement être configuré dans le fichier
postgresql.conf
ou sur la ligne de commande du
serveur.
Ces réglages contrôlent le comportement d'un souscripteur de réplication logique. Leurs valeurs sur le serveur publiant les données est sans importance. See Section 31.10 for more details.
max_replication_slots
(integer
)
#
Spécifie combien d'origines de réplication (voir Chapitre 50)
peuvent être suivies simultanément, limitant donc le nombre de
souscriptions à des réplications logiques qu'il est possible de créer sur
le serveur.
Modifier ce paramètre à une valeur inférieure au nombre de replications
suivies (remontées par la vue pg_replication_origin_status)
empêchera le serveur de démarrer.
max_replication_slots
doit être fixé au moins au
nombre d'abonnements qui seront ajoutés au souscripteur, avec une réserve
pour la synchronisation des tables.
Notez que ce paramètre est également pris en compte par le serveur émetteur, mais avec une signification différente.
max_logical_replication_workers
(integer
)
#Spécifie le nombre maximal de workers de réplication logique. Cela inclut à la fois les leader apply workers, les parallel apply 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.
max_sync_workers_per_subscription
(integer
)
#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.
max_parallel_apply_workers_per_subscription
(integer
)
#
Le nombre maximal de workers parallélisés pour un abonnement. Ce paramètre
permet de contrôler le niveau de parallélisme pour le flux de
de transaction en cours avec un paramètre d'abonnement streaming = parallel
.
Les workers parallélisés 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.