pg_createsubscriber — convertit un secondaire physique en nouveau réplica logique
pg_createsubscriber
[option
...] { -d
| --database
}nom_base
{ -D
| --pgdata
}rep_donnees
{ -P
| --publisher-server
}chaine_connexion
pg_createsubscriber crée un nouveau réplica logique à partir d'un serveur secondaire physique. Toutes les tables de la base indiquée sont incluses dans la mise en place de la réplication logique. Une paire d'objets de publication et de souscription est créée pour chaque base. Il doit être exécuté sur le serveur cible.
Après une exécution réussie, l'état du serveur cible est analogue à une configuration récente de réplication logique. La différence principale entre la configuration de réplication logique et pg_createsubscriber est la façon dont la synchronisation des données initiales est réalisée. pg_createsubscriber ne copie pas les données initiales de la table. Elle procède uniquement à la phase de synchronisation, qui assure que chaque table est amenée à un état synchronisé.
pg_createsubscriber cible les bases de données volumineuses car, dans la mise en place d'une réplication logique, la plus grande partie du temps est passée dans la copie de données initiale. De plus, un effet de bord de ce long moment passé à synchroniser les données est qu'il y a souvent un grand nombre de modifications à appliquer (celles survenues pendant la synchronisation de données), ce qui augmente encore plus la durée au bout de laquelle le réplica logique sera disponible. Pour des bases plus petites, la synchronisation de données initiale est recommendée.
pg_createsubscriber accepte les arguments suivant en ligne de commande :
-d nom_base
--database=nom_base
Le nom de la base dans laquelle créer une souscription. Plusieurs bases
peuvent être sélectionnées en ajoutant plusieurs options
-d
.
-D rep_donnees
--pgdata=rep_donnees
Le répertoire cible qui contient un répertoire d'instance d'un serveur secondaire physique.
-n
--dry-run
Fait tout, sauf modifier le répertoire cible.
-p port
--subscriber-port=port
Le numéro de port sur lequel le serveur cible écoute les demandes de connexions. Par défaut, exécute le serveur cible sur le port 50432 pour éviter les connexions clients intempestives.
-P chaine_connexion
--publisher-server=chaine_connexion
La chaîne de connexion du publieur. Pour les détails, voir Section 32.1.1.
-s dir
--socketdir=dir
Le répertoire à utiliser pour les sockets du postmaster sur le serveur cible. Par défaut, le répertoire courant.
-t seconds
--recovery-timeout=seconds
Le nombre maximum de secondes à attendre pour la fin de la restauration. Le configurer à 0 le désactive. La valeur par défaut est 0.
-U nom_utilisateur
--subscriber-username=nom_utilisateur
Le nom de l'utilisateur pour la connexion au serveur cible. Correspond par défaut au nom de l'utilisateur courant du système d'exploitation.
-v
--verbose
Active le mode verbeux. Dans ce cas, pg_createsubscriber affichera des messages de progresssion et des informations détaillées sur chaque étape, le tout sur la sortie des erreurs. Répéter cette option ajoute des messages supplémentaires de débogage.
--config-file=nom_fichier
Utilise le fichier spécifié du serveur principal pour le répertoire des
données de la cible. pg_createsubscriber
utilise en interne la commande pg_ctl pour
lancer et arrêter le serveur cible. Cela vous permet de préciser le
fichier de configuration postgresql.conf
réel s'il
est enregistré en dehors du répertoire de donnés.
--publication=nom
Le nom de la publication à configurer en réplication logique. Plusieurs
publications peuvent être précisées en écrivant plusieurs options
--publication
. Le nombre des noms de publication doit
correspondre au nombre de bases de données, sinon une erreur est
renvoyée. L'ordre de plusieurs options de publication doit correspondre
à l'ordre des options de base. Si cette option n'est pas précisée, un
nom généré est assigné comme nom de publication.
--replication-slot=nom
Le nom du slot de réplication à configurer en réplication logique.
Plusieurs slots de réplication peuvent être précisés en écrivant
plusieurs options --replication-slot
. Le nombre de noms
de slots de réplication doit correspondre au nombre de bases de données,
sinon une erreur est renvoyée. L'ordre de plusieurs options de slots de
réplication doit correspondre à l'ordre des options de base. Si cette
option n'est pas précisée, le nom de la souscription est appliqué au nom du slot de
réplication.
--subscription=nom
Le nom de la souscription à configurer en réplication logique. Plusieurs
souscriptions peuvent être précisées en écrivant plusieurs options
--subscription
. Le nombre de noms de souscription doit
correspondre au nombre de bases de données, sinon une erreur est
renvoyée. L'ordre de plusieurs options de souscription doit correspondre
à l'ordre des options de base. Si cette option n'est pas précisée, un
nom généré est assigné comme nom de la souscription.
-V
--version
Affiche la version de pg_createsubscriber, puis quitte.
-?
--help
Affiche l'aide sur les arguments en ligne de commande de pg_createsubscriber, puis quitte.
Il existe quelques prérequis pour que
pg_createsubscriber convertisse le serveur cible
en un réplica logique. S'ils ne sont pas satisfaits, une erreur sera
renvoyée. Les serveurs source et cible doivent avoir la même version
majeure que pg_createsubscriber. Le répertoire
des données cible doit avoir le même identifiant système que le répertoire
des données source. L'utilisateur de base de données pour le répertoire des
données cible doit avoir les droits pour créer des souscriptions et utiliser pg_replication_origin_advance()
.
Le serveur cible doit être utilisé comme un secondaire physique. Le serveur cible doit avoir max_replication_slots et max_logical_replication_workers configurés à une valeur supérieure ou égale au nombre de bases spécifiées. Le serveur cible doit avoir max_worker_processes configuré à une valeur supérieure au nombre de bases spécifiées. Le serveur cible doit accepter les connexions locales.
Le serveur source doit accepter les connexions du serveur cible. Le serveur
source ne doit pas être en restauration. Le serveur source doit avoir wal_level configuré à logical
. Le
serveur source doit avoir max_replication_slots
configuré à une valeur supérieure ou égale au nombre de bases spécifiées,
plus le nombre de slots de réplication préexistants. Le serveur source doit
avoir max_wal_senders configuré à une valeur
supérieure ou égale au nombre de bases spécifiées plus le nombre de
processus WAL sender existants.
Si pg_createsubscriber échoue après la promotion du serveur cible, alors le répertoire de données n'est sans doute plus dans un état récupérable. Dans de tels cas, créer un nouveau serveur secondaire est recommandé.
pg_createsubscriber démarre habituellement le serveur cible avec une configuration de la connexion différente lors de la transformation. Du coup, les connexions au serveur cible devraient échouer.
Comme les commandes DDL ne sont pas répliquées par la réplication logique, évitez d'exécuter des commandes DDL qui modifient le schéma des bases pendant l'exécution de pg_createsubscriber. Si le serveur cible a déjà été converti en un réplica logique, les commandes DDL pourraient ne pas être répliquées, ce qui causerait une erreur.
Si pg_createsubscriber échoue lors du traitement, les objets (publications, slots de réplication) créés sur le serveur source sont supprimés. La suppression peut échouer si le serveur cible ne peut pas se connecter au serveur source. Dans un tel cas, un message d'avertissement informera sur les objets laissés. Si le serveur cible est en cours d'exécution, il sera arrêté.
Si la réplication utilise primary_slot_name, il sera supprimé du serveur source après la mise en place de la réplication logique.
Si le serveur cible est un secondaire synchrone, les validations de transactions sur le primaire pourraient attendre la réplication lors de l'exécution de pg_createsubscriber.
pg_createsubscriber configure une réplication
logique avec le two-phase commit désactivé.
Ceci signifie que toute transaction préparée sera répliquée au moment du
COMMIT PREPARED
, sans avancer la préparation. Une fois
la configuration terminée, vous pouvez supprimer et recréer manuellement
les souscriptions avec l'option two_phase
activée.
pg_createsubscriber modifie l'identifiant système en utilisant pg_resetwal. Cela évite les situations où le serveur cible utiliserait les fichiers WAL du serveur source. Si le serveur cible a un secondaire, la réplication sera cassée et un nouveau secondaire devra être créé.
L'idée de base est d'avoir un point de début de réplication à partir du serveur source et de configurer la réplication logique pour qu'elle commence à partir de ce point :
Lancer le serveur cible avec les options en ligne de commande indiquées. Si le serveur cible est déjà en cours d'exécution, pg_createsubscriber s'arrête avec une erreur.
Vérifier si le serveur cible peut être converti. Il existe aussi quelques vérifications sur le serveur source. Si certains prérequis ne sont pas satisfaits, pg_createsubscriber s'arrête avec une erreur.
Créer sur le serveur source une publication et un slot de réplication
pour chaque base indiquée. Chaque publication est créée en utilisant la clause
FOR
ALL TABLES
. Si l'option publication-name
n'est pas indiquée, le nom de la publication suivra le motif suivant :
« pg_createsubscriber_%u_%x
»
(paramètres :
base oid
, nombre aléatoire
int
).
Si replication-slot-name
n'est pas indiquée, le nom du
slot de réplication suivra le motif suivant :
« pg_createsubscriber_%u_%x
»
(paramètres :
base oid
, nombre aléatoire
int
).
Ces slots de réplication seront utilisés par les souscriptions un peu plus
tard. Le LSN du dernier slot de réplication est utilisé comme point
d'arrêt dans le paramètre recovery_target_lsn, et
par les souscriptions comme le point de démarrage de la réplication. Cela
garantit qu'aucune transaction ne sera perdue.
Écrire les paramètres de restauration dans le répertoire des données cible
et redémarrer le serveur cible. L'outil lui précise le LSN
(recovery_target_lsn) de l'emplacement des WAL à
atteindre par la restauration. Il fournit aussi l'option
promote
, comme action que le serveur doit réaliser une
fois la cible de restauration atteinte. Des paramètres de
restauration supplémentaires sont ajoutés pour éviter un
comportement inattendu lors du processus de restauration, tels que la fin
de la restauration dès qu'un état cohérent est atteint (les WAL doivent
être appliqués jusqu'à l'emplacement du démarrage de la réplication), ou
diverses cibles de restauration qui peuvent causer un échec. Cette étape
se termine une fois que le serveur quitte le mode standby et accepte les
transactions en lecture/écriture. Si l'option
--recovery-timeout
est configurée,
pg_createsubscriber quitte si la restauration
ne se termine pas après ce nombre de secondes.
Sur le serveur cible, créer une souscription pour chaque base indiquée. Si
l'option subscription-name
n'est pas indiquée, le nom de la
souscription suit le motif suivant :
« pg_createsubscriber_%u_%x
»
(paramètres : base oid
, nombre aléatoire
int
). Il ne copie pas les données existantes du
serveur source. Il ne crée pas un slot de réplication. À la place, il
utilise le slot de réplication qui a été créé à l'étape précédente. La
souscription est créée mais elle n'est pas encore activée. La raison en
est que la progression de la réplication doit être configurée au point de
démarrage de la réplication avant de commencer la réplication.
Supprime les publications sur le serveur cible, qui ont été répliquées parce qu'elles ont été créées avant l'emplacement du démarrage de la réplication. Elles sont inutiles sur l'abonné.
Configure la progression de la réplication au point de démarrage de la
réplication pour chaque souscription. Quand le serveur cible commence
le processus de restauration, il récupère jusqu'au point de démarrage de
la réplication. C'est le LSN exact à utiliser comme emplacement initial
de réplication pour chaque souscription. Le nom de l'origine de
réplication est obtenu à la création de la souscription. Le nom de
l'origine de la réplication et le point de démarrage de la réplication
sont utilisés dans pg_replication_origin_advance()
pour configurer l'emplacement initial de la réplication.
Active la souscription pour chaque base spécifiée sur le serveur cible. La souscription commence l'application des transactions à partir du point de début de la réplication.
Si le serveur secondaire utilisait primary_slot_name, ce n'est plus utile, donc il est supprimé.
Si le serveur secondaire contient des slots de réplication pour failover, ils ne peuvent plus être synchronisés, donc ils sont supprimés.
Mettre à jour l'identifiant système sur le serveur cible. L'outil
pg_resetwal est exécuté pour modifier l'identifiant
système. Le serveur cible est arrêté car c'est un prérequis de
pg_resetwal
.
Pour créer un réplica logique pour les bases hr
et
finance
à partir d'un réplica physique situé sur
foo
:
$
pg_createsubscriber -D /usr/local/pgsql/data -P "host=foo" -d hr -d finance