pg_createsubscriber — convertit un secondaire physique en nouveau réplicat logique
pg_createsubscriber [option...] { -d | --database }nom_base { -D | --pgdata }rep_donnees { -P | --publisher-server }chaine_connexion
pg_createsubscriber crée un nouveau réplicat logique à partir d'un serveur secondaire physique. Toutes les tables de la base indiquée sont inclus dans la configuration de réplication logique. Une paire d'objets de publication et de souscription est créée pour chaque base. Il doit être exécuté sr 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 fait uniquement la phase de synchronisation, qui assure que chaque table est amené à un état synchronisé.
pg_createsubscriber cible les systèmes de bases volumineux car, dans une configuration de réplication logique, la plupart du temps est passée lors de la copie de données initiale. De plus, un effet de board de long moment passé à synchroniser les données est habituellement un grand nombre de modifications à appliquer (celles survenues pendant la synchronisation de données), qui augmente encore plus la durée au bout de laquelle le réplicat 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_donneesLe répertoire cible qui contient un répertoire d'instance d'un serveur secondaire physique.
-n--dry-runFait tout sauf modifier le répertoire cible.
-p port--subscriber-port=portLe numéro de port sur lequel le serveur cible est en écoute de connexions. Par défaut, exécute le serveur cible sur le port 50432 pour éviter les connexions clients inattendues.
-P chaine_connexion--publisher-server=chaine_connexionLa chaîne de connexion du publieur. Pour les détails, voir Section 32.1.1.
-s dir--socketdir=dirLe répertoire à utiliser pour les sockets de postmaster sur le serveur cible. Par défaut, le répertoire courant.
-t seconds--recovery-timeout=secondsLe nombre maximum de seconde à attendre pour la fin de la restauration. Le configurer à zéro le désactive. La valeur par défaut est 0.
-U nom_utilisateur--subscriber-username=nom_utilisateurLe nom utilisateur pour la connexion au serveur cible. Correspond par défaut au nom de l'utilisateur du système d'exploitation.
-v--verboseActive 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ébuggage.
--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 de noms de publication doit
correspondre au nombre de bases de données, sinon une erreur est
renvoyée. L'ordre des multiples 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 appliqué au 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ées 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 des multiples options de slots de
réplication doit correspondre à l'ordre des options de base. Si cette
option n'est pas précisée, un nom généré 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 des multiples 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 appliqué au nom de la souscription.
-V--versionAffiche la version de pg_createsubscriber, puis quitte.
-?--helpAffiche l'aide sur les arguments en ligne de commande de pg_createsubscriber, puis quitte.
Il existe quelques prérequis à
pg_createsubscriber pour convertir le serveur cible
en un réplicat logique. S'ils ne sont pas satisfaits, une erreur sera
renvoyée. Les serveurs source et cible doivent avoir la même version
majeur 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 donnée 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é à 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 dot 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 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 ne semble plus dans un état récupérable. Dans de tels cas, créer unnouveau serveur secondaire est recommendé.
pg_createsubscriber démarre habituellement le serveur cible avec différentes configurations de connexion 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 lors de l'exécution de pg_createsubscriber. Si le serveur cible a déjà été converti en un réplicat 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 configuration 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 re-créer manuellement
les souscriptions avec l'option two_phase
activée.
pg_createsubscriber modifie l'identifieur système en utilisant pg_resetwal. Cela évitera les situations dans lesquelles le serveur cible pourrait utiliser les fichiers WAL du serveur cible. 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êtera 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êtera avec une erreur.
Créer une publication et un slot de réplication pour chaque base indiquée
sur le serveur source. Chaque publication est créée en utilisant la clause
FOR
ALL TABLES. Si l'option nom_publication
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 nom_slot_replication 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
pour les souscriptions comme 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. Il indique un LSN
(recovery_target_lsn) de l'emplacement des WAL à
atteindre par la restauration. Il indique aussi
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 telle 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) et
plusieurs 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 en ce nombre de secondes.
Sur le serveur cible, réer une souscription pour chaque base indiquée. Si
nom_souscription n'est pas indiqué, 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éplicat logique pour les bases hr et
finance à partir d'un réplicat physique situé sur
foo :
$pg_createsubscriber -D /usr/local/pgsql/data -P "host=foo" -d hr -d finance