Vous pouvez utiliser les fonctionnalités de réplication logique et de décodage logique de Cloud SQL pour PostgreSQL. Ces fonctionnalités permettent d'utiliser des workflows de réplication logique et des workflows de capture de données modifiées.
Pour obtenir des informations générales sur la réplication, consultez la page À propos de la réplication dans Cloud SQL.
Introduction
Lorsque PostgreSQL effectue une réplication logique, les modifications transmises aux instances dupliquées sont extraites des journaux WAL à l'aide du décodage logique. Les modifications décodées sont indépendantes du format de stockage physique sous-jacent. Les modifications ne reflètent que les changements des données au niveau SQL, en termes d'instructions INSERT, UPDATE et DELETE. Cette indépendance par rapport à la couche de stockage offre une grande flexibilité et permet un large éventail de fonctionnalités pour les consommateurs des flux de modifications.
La réplication logique est la fonctionnalité phare basée sur le décodage logique.
Contrairement à la fonctionnalité de réplication physique de PostgreSQL, qui nécessite que les bases de données source et de destination aient la même version, la réplication logique permet d'effectuer la réplication entre différentes versions majeures de PostgreSQL. La réplication logique dans Cloud SQL est fournie par l'extension pglogical, disponible dans toutes les versions de PostgreSQL, et la réplication logique native de PostgreSQL, intégrée à PostgreSQL 10.
Le format dans lequel les modifications sont diffusées peut être configuré à l'aide de différents plug-ins. Cela permet de mettre en œuvre des architectures flexibles de capture de données modifiées (CDC, Change Data Capture).
Par exemple, l'extension wal2json permet de diffuser toutes les modifications d'une base de données vers un consommateur, au format JSON. Cloud SQL est compatible avec le décodeur intégré pgoutput, le module de contribution test_decoding et wal2json. Cloud SQL est actuellement compatible avec les deux variantes wal2json de sortie JSON : format-version 1 qui encode l'ensemble de la transaction en un seul objet JSON et format-version 2 qui génère un objet JSON par commande. Ces plug-ins permettent de réaliser la réplication vers des bases de données non-PostgreSQL.
Configurer une instance PostgreSQL
PostgreSQL permet d'utiliser le décodage logique en écrivant des informations supplémentaires dans son journal WAL (write-ahead log).
Dans Cloud SQL, vous activez cette fonctionnalité en définissant l'option cloudsql.logical_decoding sur on. Ce paramètre est différent de celui utilisé dans la version standard de PostgreSQL.
Si vous modifiez une instance PostgreSQL externe, vous activez cette fonctionnalité en définissant le paramètre de configuration wal_level sur logical.
Si vous prévoyez d'utiliser l'extension pglogical, vous devez ajouter pglogical à shared_preload_libraries. Comme Cloud SQL n'autorise pas la modification directe de cette option, pglogical est activé en définissant cloudsql.enable_pglogical sur on. Sur une VM, exécutez la commande sudo apt-get install postgresql-13-pglogical, puis redémarrez la base de données.
Si vous utilisez pglogical pour effectuer une réplication entre deux instances PostgreSQL, le décodage logique ne doit être activé que sur l'instance principale, et non sur l'instance dupliquée (sauf si cette instance est elle-même une instance principale pour d'autres instances dupliquées). Cependant, l'extension pglogical doit être activée sur les deux instances. Pour obtenir des exemples décrivant l'utilisation des termes "instance principale" et "instance répliquée", ainsi que leur signification, consultez la page À propos de la réplication dans Cloud SQL.
Activer la connectivité réseau
Assurez-vous que vos instances principales acceptent les connexions à partir de l'instance dupliquée.
| Principal | Instance dupliquée | Configuration |
|---|---|---|
| Cloud SQL (adresse IP publique) | Cloud SQL (adresse IP publique) | Ajoutez l'adresse IP sortante de l'instance dupliquée aux réseaux autorisés de l'instance principale. |
| Cloud SQL (adresse IP privée) | Cloud SQL (adresse IP privée) | Si les deux instances se trouvent dans le même projet Google Cloud, ajoutez la plage d'adresses IP allouée du réseau VPC de l'instance répliquée au réseau autorisé qui héberge les instances.
Pour rechercher la plage d'adresses IP allouée dans Google Cloud Console, procédez comme suit :
|
| Externe | Cloud SQL | Vous pouvez utiliser Database Migration Service. |
| Cloud SQL | Externe | Pour en savoir plus, consultez la page Configurer des instances répliquées externes. |
Obtenir l'adresse IP sortante d'une instance répliquée
Si l'instance répliquée est une instance Cloud SQL dotée d'une adresse IP publique, procédez comme suit pour obtenir son adresse IP sortante.
Console
Ouvrez la page Instances Cloud SQL.
À côté de l'adresse IP publique de l'instance dupliquée Cloud SQL, passez la souris sur l'info-bulle Plus d'infos et récupérez l'adresse IP sortante. Notez que l'adresse IP sortante ne correspond pas à l'adresse IP affichée dans la liste principale pour l'instance dupliquée dans la console Cloud.
Si l'instance répliquée n'est pas une instance Cloud SQL, reportez-vous à la documentation correspondante.
Pour en savoir plus sur l'obtention de l'adresse IP publique d'une instance, consultez la section Obtenir l'adresse IP sortante de l'instance dupliquée Cloud SQL.
gcloud
Vous pouvez exécuter la commande gcloud suivante :
gcloud sql instances describe [REPLICA_NAME] --format="default(ipAddresses)"
Autoriser les connexions
Si l'instance principale est une instance Cloud SQL, vous pouvez autoriser l'accès à partir de l'adresse IP sortante de l'instance dupliquée en l'ajoutant en tant que réseau autorisé.
Activer les connexions de réplication pour les versions 9.6 et antérieures de PostgreSQL
Si votre instance principale ne s'exécute pas dans Cloud SQL et utilise PostgreSQL 9.6 ou une version antérieure, vous devez vous assurer que le fichier pg_hba.conf
de l'instance est configuré pour accepter les connexions de réplication. Ajoutez la ligne suivante à ce fichier, en utilisant all all uniquement pour les tests initiaux. Pour plus de sécurité, limitez les utilisateurs et les adresses IP aux ressources requises uniquement, comme dans cet exemple :
host replication all all md5
Pour en savoir plus, consultez le fichier pg_hba.conf.
Créer un utilisateur de réplication
Pour utiliser les fonctionnalités de décodage logique, vous devez créer un utilisateur PostgreSQL avec l'attribut REPLICATION.
Exemples
CREATE USER replication_user WITH REPLICATION
IN ROLE cloudsqlsuperuser LOGIN PASSWORD 'secret';
Vous pouvez également définir cet attribut sur un utilisateur existant :
ALTER USER existing_user WITH REPLICATION;
Ressources PostgreSQL
Lorsque le décodage logique est utilisé, un processus en arrière-plan sur l'instance PostgreSQL principale transforme les modifications WAL en modifications logiques à l'aide du plug-in de décodage sélectionné et les transmet à un consommateur (qui peut même être une instance autre que PostgreSQL). Ce processus en arrière-plan est appelé expéditeur WAL. Le nombre d'expéditeurs WAL simultanés pouvant être actifs dans une instance PostgreSQL est limité par l'option max_wal_senders. La valeur par défaut de cette option est de 10 et sa limite augmente de manière linéaire avec la mémoire de l'instance Cloud SQL, autorisant huit expéditeurs WAL par Go de mémoire.
Pour garantir que les segments WAL ne sont pas supprimés avant d'être envoyés à tous les clients, PostgreSQL utilise des emplacements de réplication logiques pour suivre les données envoyées à chaque consommateur (et Emplacements de réplication physiques pour les instances dupliquées avec accès en lecture). Le nombre d'emplacements de réplication que vous pouvez créer pour une instance PostgreSQL est limité par l'option max_replication_slots. La valeur par défaut de cette option est de 10 et sa limite augmente avec la mémoire de votre instance Cloud SQL, autorisant entre deux et huit emplacements de réplication par Go de mémoire.
Le tableau suivant montre la relation entre la mémoire maximale d'une instance Cloud SQL et le nombre maximal d'emplacements de réplication pour cette instance.
Il existe généralement un emplacement de réplication et un expéditeur WAL par consommateur. Ces options doivent donc être définies sur des valeurs à peu près égales. Cependant, PostgreSQL recommande de fournir un petit tampon pour que max_wal_senders puisse gérer lorsque l'interruption inattendue des connexions et l'établissement de nouvelles connexions. La réplication physique, utilisée par les instances dupliquées Cloud SQL avec accès en lecture, utilise également un emplacement de réplication et un expéditeur WAL. Vous devez donc les prendre en compte lors du calcul de la quantité de chaque ressource dont vous avez besoin.
La réplication logique native PostgreSQL et l'extension pglogical ont besoin de processus supplémentaires en arrière-plan pour s'exécuter, à la fois sur l'instance principale et sur les instances dupliquées. Le nombre de processus en arrière-plan pouvant être exécutés est limité par l'option max_worker_processes. La valeur par défaut est de huit et sa limite augmente de manière linéaire avec la mémoire de l'instance Cloud SQL, autorisant deux processus supplémentaires par Go de mémoire. Le nombre exact de processus de nœud de calcul utilisés avec ces approches est expliqué dans leurs sections respectives.
Si cette option est définie sur une valeur trop faible et que la réplication échoue avec le message d'erreur worker registration failed visible dans les journaux, vous devrez probablement augmenter le paramètre max_worker_processes.
Notez que les expéditeurs WAL ne sont pas considérés comme des processus de nœud de calcul. Les nœuds de calcul générés pour l'exécution de requêtes en parallèle sont comptabilisés. Par conséquent, si la valeur définie pour max_worker_processes est trop faible, vous risquez de rencontrer des problèmes de performances, car PostgreSQL ne peut pas exploiter l'exécution de requêtes en parallèle.
Vous pouvez déterminer l'utilisation du disque WAL à l'aide de la fonction pg_ls_waldir (). Cette fonction est limitée aux utilisateurs cloudsqlsuperuser, tels que l'administrateur par défaut postgres. Cette fonction n'est disponible que dans PostgreSQL 10 et les versions ultérieures.
Pour calculer l'utilisation totale du disque WAL, procédez comme suit :
postgres=> select * from pg_ls_waldir();
| nom | taille | modification |
|---|---|---|
| 00000001000000000000000A | 16777216 | 2021-08-11 15:16:49+00 |
| 000000010000000000000009 | 16777216 | 2021-08-12 06:23:24+00 |
(2 lignes)
postgres=> select pg_size_pretty(sum(size)) as "Total WAL disk usage" from pg_ls_waldir();
| Utilisation totale du disque WAL |
|---|
| 32 Mo |
(1 ligne)
Configurer la réplication logique avec une instance dupliquée externe
Consultez la page Configurer des instances dupliquées externes pour obtenir un exemple complet utilisant pglogical et le décodage logique.
Configurer la réplication logique avec pglogical
Pour configurer la réplication logique avec pglogical, le décodage logique doit être activé sur l'instance principale. Définissez cloudsql.logical_decoding=on sur l'instance Cloud SQL ou wal_level=logical sur une instance externe. En outre, pglogical doit être activé à la fois sur l'instance principale et sur l'instance dupliquée. Définissez cloudsql.enable_pglogical=on sur une instance Cloud SQL ou ajoutez pglogical à shared_preload_libraries sur une instance externe. Notez que la modification de ces options nécessite un redémarrage des instances principale et dupliquées.
Si vous rencontrez des problèmes lors de ces étapes, consultez la section Dépannage des problèmes avec pglogical.
Créer un utilisateur avec des droits de réplication
Lorsque vous utilisez pglogical, vous devez disposer d'un utilisateur doté des droits de réplication et du rôle cloudsqlsuperuser sur les instances principale et dupliquées. Toutes les commandes décrites ci-dessous doivent être exécutées par cet utilisateur.
Installer l'extension pglogical
Vous devez installer l'extension pglogical sur les instances principale et répliquées. Sur l'instance principale, c'est l'utilisateur de la réplication (c'est-à-dire l'utilisateur qui se connecte à la base de données) qui doit l'installer.
CREATE EXTENSION pglogical;
Créer un nœud pglogical sur chaque instance
Un nœud pglogical représente une instance PostgreSQL physique et stocke les détails de connexion de cette instance. L'instance principale et l'instance dupliquée doivent s'enregistrer en tant que nœuds :
source-instance$ SELECT pglogical.create_node(
node_name := 'primary',
dsn := 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=secret'
);
dest-instance$ SELECT pglogical.create_node(
node_name := 'replica',
dsn := 'host=<replica-ip> port=5432 dbname=postgres user=replication_user password=secret'
);
Créer une table contenant les données à répliquer
L'extension pglogical permet de ne répliquer qu'un sous-ensemble de tables vers une destination. Par exemple, nous allons créer une table factice sur l'instance principale et la remplir avec des données aux fins de tests :
CREATE TABLE replica_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO replica_test (data) VALUES ('apple'), ('banana'), ('cherry');
La table doit également être créée sur l'instance dupliquée.
Ajouter la table à un ensemble de réplication
Pour gérer la réplication de différents ensembles de données vers différentes destinations, pglogical utilise le concept d'ensemble de réplication. Nous pouvons ajouter notre table de test à l'ensemble de réplication par défaut.
SELECT pglogical.replication_set_add_table('default', 'replica_test', true);
Créer l'abonnement pglogical
Créez l'abonnement pglogical sur l'instance de destination en fournissant des détails de connexion à l'instance principale.
SELECT pglogical.create_subscription(
subscription_name := 'test_sub',
provider_dsn := 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=replicapassword'
);
SELECT * FROM pglogical.show_subscription_status('test_sub');
Si l'état indique "réplication", la configuration a réussi. Interrogez la table replica_test pour vous assurer que les données ont été bien répliquées. Insérez et modifiez des enregistrements sur l'instance principale, puis vérifiez qu'ils apparaissent sur l'instance dupliquée.
Sur l'instance principale, interrogez la table pg_replication_slots pour afficher l'emplacement de réplication créé par l'abonnement.
Nettoyage
Une fois votre test réussi, supprimez l'abonnement sur l'instance dupliquée à l'aide de pglogical.drop_subscription('test_sub'). Vérifiez que l'emplacement de réplication est également supprimé sur l'instance principale. Sinon, les segments WAL continuent de s'accumuler sur l'instance dupliquée.
Pour en savoir plus sur les ensembles de réplication, la réplication partielle des données, la réplication LDD, d'autres configurations et limites avancées, consultez la documentation de pglogical.
Utilisation des ressources
L'extension pglogical exécute plusieurs processus en arrière-plan qui sont comptabilisés dans la limite max_worker_processes.
En état stable, elle exécute un processus "superviseur" lorsque celui-ci est activé, un processus "gestionnaire" par base de données PostgreSQL ayant installé l'extension (par exemple, il peut y en avoir D), et un processus d'"application" par abonnement pglogical sur l'instance dupliquée (par exemple, il peut y en avoir S).
Cependant, l'extension peut générer des processus de nœud de calcul supplémentaires lors de la synchronisation initiale et génère de fait des processus "gestionnaires" pour chaque base de données de l'instance. Toutefois, si l'extension n'est pas installée pour une base de données, elle se ferme immédiatement.
Par conséquent, allouez quelques processus de nœud de calcul de plus que nécessaire pour l'état stable. PostgreSQL utilise des processus de nœud de calcul à d'autres fins, telles que le traitement de requêtes en parallèle. Si max_worker_processes est défini sur une valeur trop faible, la réplication peut échouer sans notification, ou PostgreSQL peut ne pas être en mesure d'effectuer le traitement des requêtes en parallèle.
En résumé, les paramètres suivants sont recommandés :
max_worker_processes
>= 1 + D + 8 (on the source instance)
>= 1 + D + S + 8 (on the destination instance)
max_wal_senders >= S + 2 (on the source instance)
max_replication_slots >= S (on the source instance)
Résoudre des problèmes liés à pglogical
Impossible de créer l'extension pglogical
Lorsque vous tentez d'installer l'extension pglogical, l'erreur suivante peut se produire :
ERROR: pglogical is not in shared_preload_libraries
Lorsque vous installez pglogical dans une instance Cloud SQL, assurez-vous d'avoir défini cloudsql.enable_pglogical=on. Si vous utilisez une instance externe, ajoutez-la directement à l'option shared_preload_libraries, par exemple shared_preload_libraries=pg_stat_statements,pglogical.
Ces modifications nécessitent un redémarrage de l'instance principale.
Impossible de créer l'abonnement pglogical
Lors de la création d'un abonnement, pglogical vérifie d'abord qu'il peut utiliser les informations de connexion pour se connecter à l'instance. Il tente d'abord de créer une connexion standard, et en cas d'échec, une erreur se produit : ERROR: could not
connect to the postgresql server.
Si cette erreur se produit, assurez-vous que l'instance principale est configurée pour autoriser les connexions à partir de l'instance dupliquée et que les détails de connexion que vous avez fournis sont corrects. Des informations supplémentaires sont fournies concernant la raison pour laquelle PostgreSQL n'a pas pu établir une connexion.
Après avoir créé une connexion standard, pglogical tente d'établir une connexion de réplication spéciale. Dans PostgreSQL 9.6 et versions antérieures, ce type de connexion peut avoir une configuration d'authentification différente. Vous devez mettre à jour le fichier pg_hba.conf sur l'instance source si le message d'erreur suivant s'affiche : ERROR: could
not connect to the postgresql server in replication mode.
Le fichier pg_hba.conf utilisé par Cloud SQL comporte déjà les modifications nécessaires. Cette erreur se produit uniquement lorsque vous vous connectez à une instance externe non gérée par Cloud SQL.
La connexion en mode de réplication peut également échouer si l'instance source ne permet pas d'avoir suffisamment d'expéditeurs WAL. Si FATAL: number of requested
standby connections exceeds max_wal_senders s'affiche, augmentez max_wal_senders sur l'instance principale.
L'abonnement pglogical est indisponible
La réplication d'un abonnement pglogical peut échouer. Pour résoudre ce problème, commencez par vous assurer qu'un processus en arrière-plan est en cours d'exécution sur l'instance dupliquée. Interrogez pg_stat_activity pour vérifier qu'un processus pglogical apply est en cours d'exécution. Si ce n'est pas le cas, consultez les journaux sur le nœud de destination. Si le message worker
registration failed, s'affiche, vous pouvez augmenter le paramètre max_worker_processes.
Ensuite, assurez-vous qu'un emplacement de réplication a été créé sur l'instance principale. Sur l'instance dupliquée, la ligne figurant dans pglogical.subscription contient le nom de l'emplacement que l'abonnement tente de créer et, sur l'instance principale, vous pouvez interroger pg_replication_slots pour vérifier que l'emplacement a bien été créé.
Si aucun emplacement de réplication n'a été créé, vérifiez les journaux sur l'instance principale.
Une erreur ERROR: logical decoding requires wal_level >= logical implique que l'option wal_level n'a pas été définie sur logical. Pour résoudre ce problème, définissez cloudsql.logical_decoding=on sur l'instance principale s'il s'agit d'une instance Cloud SQL.
Si c'est une instance externe, définissez wal_level=logical.
Sinon, vous pourriez rencontrer une erreur ERROR: all replication slots are in use, ainsi que l'indication utile HINT: Free one or increase max_replication_slots.
Configurer la réplication logique PostgreSQL native
Depuis PostgreSQL 10, PostgreSQL propose une réplication logique intégrée native. Pour configurer la réplication logique native, vous devez activer le décodage logique sur l'instance principale en définissant cloudsql.logical_decoding=on sur une instance Cloud SQL ou wal_level=logical sur une instance externe. Notez que la modification de ces options nécessite un redémarrage de l'instance principale.
Assurez-vous que vos instances sont correctement configurées (pour la connectivité réseau, etc.) en consultant les sections de la page Configurer votre instance PostgreSQL. Cette page décrit la procédure à suivre pour réaliser une démonstration de faisabilité. Si vous rencontrez des problèmes lors des étapes de ces sections, consultez la page Résoudre des problèmes de pglogical. Pour en savoir plus, consultez la page Réplication logique dans la documentation PostgreSQL.
Créer une table contenant les données à répliquer
La réplication logique PostgreSQL native accepte une base de données entière ou uniquement des tables individuelles. Par exemple, nous allons créer une table factice sur l'instance principale et la remplir avec des données aux fins de tests :
CREATE TABLE native_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO native_test (data) VALUES ('apple'), ('banana'), ('cherry');
La table doit également être créée sur l'instance dupliquée.
Créer une publication sur l'instance principale
La réplication logique PostgreSQL native utilise des éditeurs et des abonnés.
Créez une publication des données dans native_test :
CREATE PUBLICATION pub FOR TABLE native_test;
Créer un abonnement sur l'instance dupliquée
Voici un exemple de création d'un abonnement sur l'instance dupliquée :
CREATE SUBSCRIPTION sub
CONNECTION 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=replicapassword'
PUBLICATION pub;
La création de l'abonnement sur l'instance dupliquée nécessite le rôle cloudsqlsuperuser. Une fois l'abonnement créé, interrogez la table native_test pour vérifier que les données sont affichées dans l'instance dupliquée.
Sur l'instance principale, vous pouvez interroger la table pg_replication_slots pour afficher l'emplacement de réplication créé par l'abonnement.
Nettoyage
Une fois votre test réussi, supprimez l'abonnement sur l'instance dupliquée à l'aide de DROP
SUBSCRIPTION sub;. Vérifiez que l'emplacement de réplication est également supprimé sur l'instance principale. Sinon, les segments WAL continuent de s'accumuler sur l'instance principale.
Limites de la réplication logique PostgreSQL native
L'accès à la colonne subconninfo de la table système pg_subscription n'est pas disponible.
L'exécution de pg_dump ne permet pas de réaliser un vidage des informations concernant les abonnements, car la commande vérifie si l'utilisateur qui se connecte dispose d'autorisations de super-utilisateur.
Recevoir des modifications WAL décodées pour la capture des données modifiées (CDC)
Comme autre cas d'utilisation de la capture des données modifiées, le décodage logique peut diffuser des modifications à partir d'une instance PostgreSQL. L'outil standard utilisé pour cela est pg_recvlogical.
Vous pouvez utiliser l'outil pg_recvlogical pour créer un emplacement de réplication et diffuser les modifications suivies par cet emplacement. Le format des modifications est déterminé par le choix du plug-in de décodage. Voici vos options :
wal2json, pour diffuser les modifications au format JSON, ou
test_decoding, pour diffuser les modifications mises en forme dans un format de texte brut.
Créer un emplacement de réplication
Pour créer un emplacement de réplication, exécutez la commande suivante :
pg_recvlogical
-h <instance_ip> \
-U <replication_user> \
-p 5432 \
-d postgres \
--slot test_slot \
--create-slot \
-P <decoder_plugin>
Diffuser les modifications
Dans un terminal Cloud Shell, exécutez :
pg_recvlogical
-h <instance_ip> \
-U <replication_user> \
-p 5432 \
-d postgres \
--slot test_slot \
--start \
-f -
Depuis un autre terminal Cloud Shell, connectez-vous à votre base de données et exécutez les commandes suivantes :
CREATE TABLE cdc_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO cdc_test (data) VALUES ('apple', 'banana');
UPDATE cdc_test SET data = 'cherry' WHERE id = 2;
DELETE FROM cdc_test WHERE id = 1;
DROP TABLE cdc_test;
Si vous utilisez le plug-in de décodeur wal2json, un résultat semblable au résultat suivant s'affiche dans le premier terminal Cloud Shell :
{"change":[]}
{"change":[{"kind":"insert","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[1,"apple"]},{"kind":"insert","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[2,"banana"]}]}
{"change":[{"kind":"update","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[2,"cherry"],"oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[2]}}]}
{"change":[{"kind":"delete","schema":"public","table":"cdc_test","oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[1]}}]}
{"change":[]}
Si vous utilisez le plug-in de décodeur test_decoding, un résultat semblable au résultat suivant s'affiche dans le premier terminal Cloud Shell :
BEGIN 19460
COMMIT 19460
BEGIN 19461
table public.cdc_test: INSERT: id[integer]:1 data[text]:'apple'
table public.cdc_test: INSERT: id[integer]:2 data[text]:'banana'
COMMIT 19461
BEGIN 19462
table public.cdc_test: UPDATE: id[integer]:2 data[text]:'cherry'
COMMIT 19462
BEGIN 19463
table public.cdc_test: DELETE: id[integer]:1
COMMIT 19463
BEGIN 19464
COMMIT 19464
(Vos ID de transaction peuvent être différents.)
Nettoyage
Une fois vos tests terminés, supprimez l'emplacement de réplication que vous avez créé en exécutant la commande suivante :
pg_recvlogical
-h <instance_ip> \
-U <replication_user> \
-p 5432 \
-d postgres \
--slot test_slot \
--drop-slot
Remarques et limites
Les remarques et limites répertoriées dans cette section s'appliquent aux fonctionnalités de réplication et de décodage logiques de Cloud SQL pour PostgreSQL.
L'extension
pglogicalne fonctionne pas dans les instances où l'application des connecteurs est activée. Cette limitation ne s'applique pas aux instances pour lesquelles l'accès aux services privés est configuré.Lorsque vous restaurez une instance pour laquelle
cloudsql.logical_decodingoucloudsql.enable_pglogicalest activé et qui agit actuellement en tant qu'éditeur pour la réplication logique, vous devez d'abord désactiver la réplication sur toutes les instances cibles. Sinon, la restauration de l'instance échoue avec une erreur, sans que les détails de l'erreur ne soient actuellement visibles.Lorsque vous restaurez une sauvegarde d'une instance pour laquelle
cloudsql.logical_decodingoucloudsql.enable_pglogicalest activé (au moment de la sauvegarde), et que vous la restaurez sur une nouvelle instance, l'état de réplication n'est pas restauré sur la nouvelle instance. Vous devez reconfigurer la réplication manuellement par la suite.Sur une instance Cloud SQL avec une ou plusieurs instances répliquées avec accès en lecture Cloud SQL (à l'aide de la réplication physique), si vous activez
cloudsql.logical_decodingoucloudsql.enable_pglogical, ces options sont également activées sur l'instance répliquée avec accès en lecture.Les instances répliquées avec accès en lecture de Cloud SQL ne peuvent pas agir en tant qu'éditeurs pour la réplication logique, car PostgreSQL n'est pas compatible avec le décodage logique dans les instances répliquées avec accès en lecture. Cependant, les options sont activées sur l'instance répliquée avec accès en lecture afin de s'assurer qu'elle peut servir d'instance de remplacement pour l'instance principale si et quand elle est promue.
L'activation de
cloudsql.logical_decodingoucloudsql.enable_pglogicalsur l'instance principale entraîne l'activation des options sur toutes les instances répliquées avec accès en lecture. Cela entraîne le redémarrage progressif des instances principales et des instances en lecture. Pour éviter cette situation et contrôler le moment où chaque instance est redémarrée, vous pouvez (1) définir les options sur chaque instance répliquée avec accès en lecture, puis (2) définir les options sur l'instance principale.La désactivation de
cloudsql.logical_decodingoucloudsql.enable_pglogicalsur l'instance principale n'entraîne pas la désactivation des options sur toutes les instances répliquées avec accès en lecture. Pour désactiver les options sur les instances, vous devez effectuer l'inverse des étapes décrites ci-dessus : (1) désactiver les options sur l'instance principale, puis (2) désactiver les options sur chaque instance répliquée avec accès en lecture.