Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Utilisation de pglogical pour synchroniser les données entre les instances Toutes les versions d’Aurora PostgreSQL actuellement disponibles prennent en charge l’extension `pglogical`. L’extension pglogical est antérieure à la fonction de réplication logique qui fonctionne de la même manière et qui a été introduite par PostgreSQL dans la version 10. Pour plus d’informations, consultez [Présentation de la réplication logique PostgreSQL avec Aurora](AuroraPostgreSQL.Replication.Logical.md). L’extension `pglogical` prend en charge la réplication logique entre deux ou plusieurs clusters de bases de données Aurora PostgreSQL. Elle prend également en charge la réplication entre différentes versions de PostgreSQL, ainsi qu’entre des bases de données fonctionnant sur RDS pour les instances de base de données PostgreSQL et les clusters de bases de données Aurora PostgreSQL. L’extension `pglogical` utilise un modèle de publication et d’abonnement pour répliquer les changements apportés aux tables et aux autres objets, tels que les séquences, d’un serveur de publication à un abonné. Elle s’appuie sur un emplacement de réplication pour assurer la synchronisation des changements d’un nœud de serveur de publication à un nœud abonné, défini comme suit. + Le *nœud de serveur de publication* est le cluster de bases de données Aurora PostgreSQL qui est la source des données à répliquer vers les autres nœuds. Le nœud de serveur de publication définit les tables à répliquer dans un ensemble de publication. + Le *nœud abonné* est le cluster de bases de données Aurora PostgreSQL qui reçoit les mises à jour WAL du serveur de publication. L’abonné crée un abonnement pour se connecter au serveur de publication et obtenir les données WAL décodées. Lorsque l’abonné crée l’abonnement, l’emplacement de réplication est créé sur le nœud de serveur de publication. Vous trouverez ci-après des informations sur la configuration de l’extension `pglogical`. **Topics** + [Exigences et limites de l’extension pglogique](#Appendix.PostgreSQL.CommonDBATasks.pglogical.requirements-limitations) + [Configuration de l'extension pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md) + [Configuration de la réplication logique pour le cluster de bases de données Aurora PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.setup-replication.md) + [Rétablissement de la réplication logique après une mise à niveau majeure](Appendix.PostgreSQL.CommonDBATasks.pglogical.recover-replication-after-upgrade.md) + [Gestion des emplacements de réplication logiques pour Aurora PostgreSQL RDS pour](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md) + [Référence des paramètres de l'extension pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.reference.md) ## Exigences et limites de l’extension pglogique Toutes les versions actuellement disponibles d’Aurora PostgreSQL prennent en charge l’extension `pglogical`. Le nœud de serveur de publication et le nœud abonné doivent tous deux être configurés pour la réplication logique. Les tables que vous voulez répliquer d’un diffuseur de publication à un abonné doivent avoir les mêmes noms et le même schéma. Ces tables doivent également contenir les mêmes colonnes, et les colonnes doivent utiliser les mêmes types de données. Les tables des serveurs de publication et des abonnés doivent avoir les mêmes clés primaires. Nous vous recommandons d’utiliser uniquement PRIMARY KEY comme contrainte unique. Les tables du nœud abonné peuvent avoir des contraintes plus permissives que celles du nœud de serveur de publication pour les contraintes CHECK et NOT NULL. L’extension `pglogical` fournit des fonctionnalités telles que la réplication bidirectionnelle qui ne sont pas prises en charge par la fonctionnalité de réplication logique intégrée à PostgreSQL (versions 10 et ultérieures). Pour plus d’informations, consultez [PostgreSQL bi-directional replication using pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/) (Réplication bidirectionnelle PostgreSQL utilisant pglogical). # Configuration de l'extension pglogical Pour configurer l'extension `pglogical` sur votre cluster de bases de données Aurora PostgreSQL, vous ajoutez `pglogical` aux bibliothèques partagées sur le groupe de paramètres de cluster de bases de données personnalisé pour votre cluster de bases de données Aurora PostgreSQL. Vous devez également définir la valeur du paramètre `rds.logical_replication` sur `1`, pour activer le décodage logique. Enfin, vous créez l'extension dans la base de données. Vous pouvez utiliser le AWS Management Console ou AWS CLI pour ces tâches. Vous devez disposer d'autorisations en tant que rôle `rds_superuser` pour effectuer ces tâches. Les étapes suivantes supposent que votre cluster de bases de données Aurora PostgreSQL est associé(e) à un groupe de paramètres de cluster de bases de données personnalisé. Pour plus d’informations sur la création d’un groupe de paramètres de cluster de bases de données, consultez [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md). ## Console **Pour configurer l'extension pglogical** 1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse. 1. Dans le panneau de navigation, choisissez l’instance d’enregistreur de votre cluster de bases de données Aurora PostgreSQL . 1. Ouvrez l’onglet **Configuration** de l’instance d’enregistreur de votre cluster de bases de données Aurora PostgreSQL. Parmi les détails de l’instance, trouvez le lien **Groupe de paramètres**. 1. Cliquez sur le lien pour ouvrir les paramètres personnalisés associés à votre cluster de bases de données Aurora PostgreSQL. 1. Dans le champ de recherche **Parameters** (Paramètres), tapez `shared_pre` pour trouver le paramètre `shared_preload_libraries`. 1. Choisissez **Edit parameters** (Modifier les paramètres) pour accéder aux valeurs des propriétés. 1. Ajoutez `pglogical` à la liste dans le champ **Values** (Valeurs). Utilisez une virgule pour séparer les éléments de la liste de valeurs. ![\[Image du paramètre shared_preload_libraries avec pglogical ajouté.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/apg_rpg_shared_preload_pglogical.png) 1. Recherchez le paramètre `rds.logical_replication` et définissez-le sur `1`, pour activer la réplication logique. 1. Redémarrez l'instance d'écriture de votre cluster de bases de données Aurora PostgreSQL pour que vos modifications soient prises en compte. 1. Lorsque l'instance est disponible, vous pouvez utiliser `psql` (ou pgAdmin) pour vous connecter à l'instance d'écriture de votre cluster de bases de données Aurora PostgreSQL. ``` psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb ``` 1. Pour vérifier que pglogical est initialisé, exécutez la commande suivante. ``` SHOW shared_preload_libraries; shared_preload_libraries -------------------------- rdsutils,pglogical (1 row) ``` 1. Vérifiez le paramètre qui active le décodage logique, comme suit. ``` SHOW wal_level; wal_level ----------- logical (1 row) ``` 1. Créez l'extension, comme suit. ``` CREATE EXTENSION pglogical; EXTENSION CREATED ``` 1. Sélectionnez **Enregistrer les modifications**. 1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Sélectionnez votre instance d'écriture du cluster de bases de données Aurora PostgreSQL dans la liste des bases de données, puis choisissez **Reboot** (Redémarrer) dans le menu Actions. ## AWS CLI **Pour configurer l'extension pglogical** Pour configurer pglogical à l'aide de AWS CLI, vous devez appeler l'[modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html)opération pour modifier certains paramètres de votre groupe de paramètres personnalisé, comme indiqué dans la procédure suivante. 1. Utilisez la AWS CLI commande suivante pour ajouter des éléments `pglogical` au `shared_preload_libraries` paramètre. ``` aws rds modify-db-parameter-group \ --db-parameter-group-name custom-param-group-name \ --parameters "ParameterName=shared_preload_libraries,ParameterValue=pglogical,ApplyMethod=pending-reboot" \ --region aws-region ``` 1. Utilisez la AWS CLI commande suivante pour définir sur `rds.logical_replication` `1` afin d'activer la fonctionnalité de décodage logique pour l'instance d'écriture du cluster de base de données Aurora PostgreSQL. ``` aws rds modify-db-parameter-group \ --db-parameter-group-name custom-param-group-name \ --parameters "ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot" \ --region aws-region ``` 1. Utilisez la AWS CLI commande suivante pour redémarrer l'instance d'écriture de votre instance de base de données Aurora PostgreSQL afin que la bibliothèque pglogical soit initialisée. ``` aws rds reboot-db-instance \ --db-instance-identifier writer-instance \ --region aws-region ``` 1. Lorsque l'instance est disponible, utilisez `psql` pour vous connecter à l'instance d'écriture de votre cluster de bases de données Aurora PostgreSQL. ``` psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb ``` 1. Créez l'extension, comme suit. ``` CREATE EXTENSION pglogical; EXTENSION CREATED ``` 1. Redémarrez l'instance d'écriture de votre instance de base de données Aurora PostgreSQL suivante. AWS CLI ``` aws rds reboot-db-instance \ --db-instance-identifier writer-instance \ --region aws-region ``` # Configuration de la réplication logique pour le cluster de bases de données Aurora PostgreSQL La procédure suivante vous montre comment démarrer la réplication logique entre deux clusters de bases de données Aurora PostgreSQL.. Les étapes supposent que la source (serveur de publication) et la cible (abonné) ont toutes deux l’extension `pglogical` configurée comme indiqué dans le document [Configuration de l'extension pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md). **Note** Le `node_name` du nœud d’un abonné ne peut pas commencer par `rds`. **Pour créer le nœud de serveur de publication et définir les tables à répliquer** Ces étapes supposent que votre cluster de bases de données Aurora PostgreSQL possède une instance d’enregistreur avec une base de données qui contient une ou plusieurs tables que vous voulez répliquer vers un autre nœud. Vous devez recréer la structure de la table du serveur de publication sur l’abonné, donc d’abord, récupérer la structure de la table si nécessaire. Vous pouvez le faire en utilisant la métacommande `psql` `\d tablename` et en créant ensuite la même table sur l’instance de l’abonné. La procédure suivante crée un exemple de table sur le serveur de publication (source) à des fins de démonstration. 1. Utilisez `psql` pour vous connecter à l’instance qui possède la table que vous voulez utiliser comme source pour les abonnés. ``` psql --host=source-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb ``` Si vous ne disposez pas d’une table existante que vous souhaitez répliquer, vous pouvez créer un exemple de table comme suit. 1. Créez un exemple de table en utilisant l’instruction SQL suivante. ``` CREATE TABLE docs_lab_table (a int PRIMARY KEY); ``` 1. Remplissez la table avec les données générées en utilisant l’instruction SQL suivante. ``` INSERT INTO docs_lab_table VALUES (generate_series(1,5000)); INSERT 0 5000 ``` 1. Vérifiez que les données existent dans la table à l’aide de l’instruction SQL suivante. ``` SELECT count(*) FROM docs_lab_table; ``` 1. Identifiez ce cluster de bases de données Aurora PostgreSQL comme le nœud de serveur de publication, comme suit. ``` SELECT pglogical.create_node( node_name := 'docs_lab_provider', dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 dbname=labdb'); create_node ------------- 3410995529 (1 row) ``` 1. Ajoutez la table que vous souhaitez répliquer à l’ensemble de réplication par défaut. Pour plus d’informations sur les ensembles de réplication, consultez [Replication sets](https://github.com/2ndQuadrant/pglogical/tree/REL2_x_STABLE/docs#replication-sets) (Ensembles de réplication) dans la documentation pglogical. ``` SELECT pglogical.replication_set_add_table('default', 'docs_lab_table', 'true', NULL, NULL); replication_set_add_table --------------------------- t (1 row) ``` La configuration du nœud de diffuseur de publication est terminée. Vous pouvez maintenant configurer le nœud abonné pour recevoir les mises à jour du serveur de publication. **Pour configurer le nœud abonné et créer un abonnement pour recevoir des mises à jour** Ces étapes supposent que le cluster de bases de données Aurora PostgreSQL a été configuré avec l’extension `pglogical`. Pour plus d’informations, consultez [Configuration de l'extension pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md). 1. Utilisez `psql` pour vous connecter à l’instance qui doit recevoir les mises à jour du serveur de publication. ``` psql --host=target-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb ``` 1. Sur le cluster de bases de données Aurora PostgreSQL de l’abonné, créez la même table que celle qui existe sur le serveur de publication. Pour cet exemple, la table est `docs_lab_table`. Vous pouvez créer la table comme suit. ``` CREATE TABLE docs_lab_table (a int PRIMARY KEY); ``` 1. Vérifiez que cette table est vide. ``` SELECT count(*) FROM docs_lab_table; count ------- 0 (1 row) ``` 1. Identifiez ce cluster de bases de données Aurora PostgreSQL comme le nœud abonné, comme suit. ``` SELECT pglogical.create_node( node_name := 'docs_lab_target', dsn := 'host=target-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=********'); create_node ------------- 2182738256 (1 row) ``` 1. Créez l’abonnement. ``` SELECT pglogical.create_subscription( subscription_name := 'docs_lab_subscription', provider_dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=*******', replication_sets := ARRAY['default'], synchronize_data := true, forward_origins := '{}' ); create_subscription --------------------- 1038357190 (1 row) ``` Lorsque vous terminez cette étape, les données de la table du serveur de publication sont créées dans la table de l’abonné. Vous pouvez le vérifier en utilisant la requête SQL suivante. ``` SELECT count(*) FROM docs_lab_table; count ------- 5000 (1 row) ``` À partir de ce moment, les modifications apportées à la table sur le serveur de publication sont répliquées sur la table sur l’abonné. # Rétablissement de la réplication logique après une mise à niveau majeure Avant de pouvoir effectuer une mise à niveau majeure d'un cluster de bases de données Aurora PostgreSQL qui est configuré comme un nœud d'édition pour la réplication logique, vous devez supprimer tous les emplacements de réplication, même ceux qui ne sont pas actifs. Nous vous recommandons de détourner temporairement les transactions de base de données du nœud d'édition, de supprimer les emplacements de réplication, de mettre à niveau le cluster de bases de données Aurora PostgreSQL, puis de rétablir et de relancer la réplication. Les emplacements de réplication sont hébergés uniquement sur le nœud de serveur de publication. Le nœud abonné Aurora PostgreSQL dans un scénario de réplication logique n'a pas d'emplacements à supprimer. Le processus de mise à niveau de la version majeure d'Aurora PostgreSQL prend en charge la mise à niveau de l'abonné vers une nouvelle version majeure de PostgreSQL indépendamment du nœud de serveur de publication. Cependant, le processus de mise à niveau perturbe le processus de réplication et interfère avec la synchronisation des données WAL entre le nœud de serveur de publication et le nœud abonné. Vous devez rétablir la réplication logique entre le serveur de publication et l'abonné après avoir mis à niveau le serveur de publication, l'abonné ou les deux. La procédure suivante vous montre comment déterminer que la réplication a été perturbée et comment résoudre le problème. ## Détermination de la perturbation de la réplication logique Vous pouvez déterminer que le processus de réplication a été interrompu en interrogeant le nœud de serveur de publication ou le nœud abonné, comme suit. **Pour vérifier le nœud de serveur de publication** + Utilisez `psql` pour vous connecter au nœud de serveur de publication, puis interrogez la fonction `pg_replication_slots`. Notez la valeur dans la colonne active. Normalement, cela renvoie la valeur `t` (true), ce qui montre que la réplication est active. Si la requête renvoie la valeur `f` (false), cela indique que la réplication vers l'abonné a cessé. ``` SELECT slot_name,plugin,slot_type,active FROM pg_replication_slots; slot_name | plugin | slot_type | active -------------------------------------------+------------------+-----------+-------- pgl_labdb_docs_labcb4fa94_docs_lab3de412c | pglogical_output | logical | f (1 row) ``` **Pour vérifier le nœud abonné** Sur le nœud abonné, vous pouvez vérifier l'état de la réplication de trois manières différentes. + Consultez les journaux PostgreSQL sur le nœud abonné pour trouver des messages d'échec. Le journal identifie l'échec avec des messages qui incluent le code de sortie 1, comme indiqué ci-dessous. ``` 2022-07-06 16:17:03 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 14610) exited with exit code 1 2022-07-06 16:19:44 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 21783) exited with exit code 1 ``` + Interrogez la fonction `pg_replication_origin`. Connectez-vous à la base de données sur le nœud abonné en utilisant `psql` et interrogez la fonction `pg_replication_origin`, comme suit. ``` SELECT * FROM pg_replication_origin; roident | roname ---------+-------- (0 rows) ``` L'ensemble de résultats vide signifie que la réplication a été perturbée. Normalement, vous obtenez un résultat qui ressemble au suivant. ``` roident | roname ---------+---------------------------------------------------- 1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c (1 row) ``` + Interrogez la fonction `pglogical.show_subscription_status` comme indiqué dans l'exemple suivant. ``` SELECT subscription_name,status,slot_name FROM pglogical.show_subscription_status(); subscription_name | status | slot_name ---====----------------+--------+------------------------------------- docs_lab_subscription | down | pgl_labdb_docs_labcb4fa94_docs_lab3de412c (1 row) ``` Cette sortie montre que la réplication a été perturbée. Son statut est `down`. Normalement, la sortie indique le statut `replicating`. Si votre processus de réplication logique a été perturbé, vous pouvez rétablir la réplication en suivant les étapes suivantes. **Pour rétablir la réplication logique entre les nœuds de serveur de publication et abonné.** Pour rétablir la réplication, vous devez d'abord déconnecter l'abonné du nœud de serveur de publication, puis rétablir l'abonnement, comme indiqué dans les étapes suivantes. 1. Connectez-vous au nœud abonné à l'aide de `psql`, comme suit. ``` psql --host=222222222222.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb ``` 1. Désactivez l'abonnement en utilisant la fonction `pglogical.alter_subscription_disable`. ``` SELECT pglogical.alter_subscription_disable('docs_lab_subscription',true); alter_subscription_disable ---------------------------- t (1 row) ``` 1. Obtenez l'identifiant du nœud de serveur de publication en interrogeant `pg_replication_origin`, comme suit. ``` SELECT * FROM pg_replication_origin; roident | roname ---------+------------------------------------- 1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c (1 row) ``` 1. Utilisez la réponse de l'étape précédente avec la commande `pg_replication_origin_create` pour attribuer l'identifiant qui peut être utilisé par l'abonnement lorsqu'il est rétabli. ``` SELECT pg_replication_origin_create('pgl_labdb_docs_labcb4fa94_docs_lab3de412c'); pg_replication_origin_create ------------------------------ 1 (1 row) ``` 1. Activez l'abonnement en transmettant son nom avec un statut `true`, comme indiqué dans l'exemple suivant. ``` SELECT pglogical.alter_subscription_enable('docs_lab_subscription',true); alter_subscription_enable --------------------------- t (1 row) ``` Vérifiez le statut du nœud. Son statut doit être `replicating`, tel qu'indiqué dans cet exemple. ``` SELECT subscription_name,status,slot_name FROM pglogical.show_subscription_status(); subscription_name | status | slot_name -------------------------------+-------------+------------------------------------- docs_lab_subscription | replicating | pgl_labdb_docs_lab98f517b_docs_lab3de412c (1 row) ``` Vérifiez le statut de l'emplacement de réplication de l'abonné sur le nœud de serveur de publication. La colonne `active` de l'emplacement doit retourner `t` (true), indiquant que la réplication a été rétablie. ``` SELECT slot_name,plugin,slot_type,active FROM pg_replication_slots; slot_name | plugin | slot_type | active -------------------------------------------+------------------+-----------+-------- pgl_labdb_docs_lab98f517b_docs_lab3de412c | pglogical_output | logical | t (1 row) ``` # Gestion des emplacements de réplication logiques pour Aurora PostgreSQL RDS pour Avant de pouvoir effectuer une mise à niveau de version majeure sur une instance de base de données RDS for PostgreSQL qui sert de nœud de serveur de publication dans un scénario de réplication logique, vous devez supprimer les emplacements de réplication sur l'instance. Le processus de pré-vérification des mises à niveau de versions majeures vous informe que la mise à niveau ne peut pas avoir lieu tant que les emplacements ne sont pas supprimés. Pour identifier les emplacements de réplication qui ont été créés à l'aide de l'extension `pglogical`, connectez-vous à chaque base de données et obtenez le nom des nœuds. Lorsque vous interrogez le nœud abonné, vous obtenez à la fois le nœud de serveur de publication et le nœud abonné dans la sortie, comme le montre cet exemple. ``` SELECT * FROM pglogical.node; node_id | node_name ------------+------------------- 2182738256 | docs_lab_target 3410995529 | docs_lab_provider (2 rows) ``` Vous pouvez obtenir les détails de l'abonnement avec la requête suivante. ``` SELECT sub_name,sub_slot_name,sub_target FROM pglogical.subscription; sub_name | sub_slot_name | sub_target ----------+--------------------------------+------------ docs_lab_subscription | pgl_labdb_docs_labcb4fa94_docs_lab3de412c | 2182738256 (1 row) ``` Vous pouvez maintenant supprimer l'abonnement, comme suit. ``` SELECT pglogical.drop_subscription(subscription_name := 'docs_lab_subscription'); drop_subscription ------------------- 1 (1 row) ``` Après avoir supprimé l'abonnement, vous pouvez supprimer le nœud. ``` SELECT pglogical.drop_node(node_name := 'docs-lab-subscriber'); drop_node ----------- t (1 row) ``` Vous pouvez vérifier que le nœud n'existe plus, comme suit. ``` SELECT * FROM pglogical.node; node_id | node_name ---------+----------- (0 rows) ``` # Référence des paramètres de l'extension pglogical Dans le tableau, vous pouvez trouver les paramètres associés à l'extension `pglogical`. Les paramètres tels que `pglogical.conflict_log_level` et `pglogical.conflict_resolution` sont utilisés pour gérer les conflits de mise à jour. Des conflits peuvent survenir lorsque des modifications sont apportées localement aux mêmes tables qui sont abonnées aux modifications du serveur de publication. Des conflits peuvent également se produire au cours de divers scénarios, tels que la réplication bidirectionnelle ou lorsque plusieurs abonnés se répliquent à partir du même serveur de publication. Pour plus d'informations, consultez [PostgreSQL bi-directional replication using pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/) (Réplication bidirectionnelle PostgreSQL utilisant pglogical). | Paramètre | Description | | --- | --- | | pglogical.batch\$1inserts | Insertions de lots si possible Non défini par défaut. Remplacez par « 1 » pour activer, par « 0 » pour désactiver. | | pglogical.conflict\$1log\$1level | Définit le niveau de journalisation à utiliser pour la journalisation des conflits résolus. Les valeurs de chaîne prises en charge sont debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, panic. | | pglogical.conflict\$1resolution | Définit la méthode à utiliser pour résoudre les conflits lorsque ceux-ci sont résolubles. Les valeurs de chaîne prises en charge sont error, apply\$1remote, keep\$1local, last\$1update\$1wins, first\$1update\$1wins. | | pglogical.extra\$1connection\$1options | Options de connexion à ajouter à toutes les connexions de nœuds de pairs. | | pglogical.synchronous\$1commit | valeur de validation synchrone spécifique pglogical | | pglogical.use\$1spi | Utilisez l'interface de programmation du serveur (SPI) au lieu de l'API de bas niveau pour appliquer les modifications. Définissez sur « 1 » pour activer, sur « 0 » pour désactiver. Pour plus d'informations sur SPI, consultez [Server Programming Interface](https://www.postgresql.org/docs/current/spi.html) (Interface de programmation du serveur) dans la documentation PostgreSQL. |