ApsaraDB RDS:Utiliser un slot de réplication pour le CDC

Prérequis

• Vous disposez d'une instance ApsaraDB RDS for PostgreSQL. Pour plus d'informations, consultez la page Créer une instance ApsaraDB RDS for PostgreSQL.

• Vous avez configuré une liste blanche pour autoriser l'accès client à l'instance ApsaraDB RDS for PostgreSQL. Pour plus d'informations, consultez la page Configurer une liste blanche d'adresses IP.

• Vous avez installé le client en ligne de commande PostgreSQL. Pour plus d'informations, consultez la documentation officielle de PostgreSQL.

Notes d'utilisation

• L'activation du CDC et la consommation des modifications de données sont possibles uniquement sur l'instance principale. Cette fonctionnalité n'est pas prise en charge sur les instances en lecture seule.

• ApsaraDB RDS for PostgreSQL prend en charge le basculement des slots de réplication logique. Un basculement entre l'instance principale et l'instance secondaire n'affecte pas le CDC. Pour plus d'informations, consultez la page Basculement des slots de réplication logique.

• Avant d'activer le CDC, vous devez modifier un paramètre de votre instance ApsaraDB RDS for PostgreSQL. Cette action entraîne le redémarrage de l'instance. Pour éviter toute interruption de service, effectuez cette opération pendant les heures creuses.

• Lorsque vous utilisez le CDC sur une instance ApsaraDB RDS for PostgreSQL, tenez compte des points suivants :

  • Le CDC nécessite davantage d'espace de stockage pour les journaux WAL. Si la consommation de données est anormale ou s'arrête, l'instance ne nettoie pas automatiquement les journaux WAL. Cela peut entraîner une accumulation des journaux et saturer tout l'espace disque disponible, ce qui risque de verrouiller l'instance. Une instance verrouillée passe en mode lecture seule et rejette les opérations d'écriture.

  • La conservation des anciennes lignes de données pendant une période prolongée peut provoquer un problème de bouclage des ID de transaction, bloquant ainsi toutes les opérations d'écriture sur l'instance. Le journal des erreurs peut contenir les messages suivants :

    “HINT: Close open transactions soon to avoid wraparound problems. You might also need to commit or roll back old prepared transactions, or drop stale replication slots.”
    “WARNING: oldest xmin is far in the past.”

  Supprimez manuellement le slot de réplication pour permettre au noyau PostgreSQL de nettoyer automatiquement les anciens journaux WAL et les lignes de données. Pour plus d'informations, consultez la section Désactiver le CDC.

  Remarque

  Surveillez régulièrement la taille des journaux WAL et l'utilisation de l'espace disque de votre instance, et configurez les alertes appropriées. Pour plus d'informations, consultez les pages Afficher les données de surveillance améliorée et Gérer les règles d'alerte.

Activer le CDC

Étape 1 : Créer une base de données de test

1. Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où se trouve l'instance RDS. Recherchez ensuite l'instance RDS et cliquez sur son ID.

2. Dans le volet de navigation de gauche, choisissez Databases.

3. Cliquez sur Create Database. Une fois la base de données testdb créée, son statut passe à Running et son jeu de caractères est défini sur UTF8.

   Remarque

   Dans cet exemple, une base de données nommée testdb est créée. Pour obtenir des instructions détaillées, consultez la page Créer une base de données.

Étape 2 : Créer des comptes de test et configurer les autorisations

1. Dans le volet de navigation de gauche, choisissez Accounts.

2. Cliquez sur Create Account pour créer un compte privilégié (db_admin) et un compte standard pour le CDC (cdc_user).

   Remarque

   Les noms de comptes utilisés dans cette rubrique le sont à titre d'exemple. Vous pouvez spécifier des noms personnalisés. Pour plus d'informations sur la création d'un compte, consultez la page Créer un compte.

3. Utilisez le compte db_admin pour vous connecter à l'instance ApsaraDB RDS for PostgreSQL.

   psql -h <endpoint of the ApsaraDB RDS for PostgreSQL instance> -p 5432 -U db_admin -d testdb

   Remarque

   Pour plus d'informations sur l'obtention du endpoint d'une instance, consultez la page Afficher ou modifier le endpoint et le numéro de port.

4. Exécutez la commande suivante pour ajouter le compte cdc_user au rôle de réplication :

   ALTER USER cdc_user WITH REPLICATION;

   Vérifiez le résultat en exécutant la commande suivante :

   SELECT rolreplication FROM  pg_roles WHERE rolname='cdc_user';

   Exemple de sortie :

    rolreplication
   ----------------
    t
   (1 row)

5. Exécutez la commande suivante pour accorder des autorisations au compte cdc_user :

   GRANT SELECT ON ALL TABLES IN SCHEMA PUBLIC to cdc_user;

Étape 3 : Modifier les paramètres de l'instance

1. Interrogez les paramètres actuels en exécutant la commande suivante :

   SELECT name,
          setting,
          short_desc,
          source
   FROM pg_settings
   WHERE name ='wal_level';

   Exemple de sortie :

            name          | setting |                               short_desc                                |       source
   -----------------------+---------+-------------------------------------------------------------------------+--------------------
    wal_level             | replica | Sets the level of information written to the WAL.                       | configuration file
   (1 rows)

   Le paramètre wal_level contrôle la quantité d'informations que PostgreSQL écrit dans le journal WAL. La valeur par défaut est replica. Ce paramètre ne peut être défini qu'au démarrage du serveur. Valeurs valides :

   • minimal : Écrit uniquement les informations nécessaires pour récupérer après un plantage ou un arrêt immédiat. À ce niveau, vous ne pouvez pas restaurer une base de données à partir d'une sauvegarde de base et des journaux WAL.

   • replica : Écrit suffisamment d'informations pour prendre en charge l'archivage WAL et la réplication, y compris l'exécution de requêtes en lecture seule sur un serveur standby.

   • logical : Ajoute les informations requises pour le décodage logique.

2. Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où se trouve l'instance RDS. Recherchez ensuite l'instance RDS et cliquez sur son ID.

3. Dans le volet de navigation de gauche, choisissez Parameters.

4. Définissez le paramètre wal_level sur logical.

   Remarque

   • Pour plus d'informations sur la modification des paramètres de l'instance, consultez la page Modifier les paramètres d'une instance ApsaraDB RDS for PostgreSQL.

   • Après avoir envoyé la modification du paramètre, votre instance ApsaraDB RDS for PostgreSQL redémarre. Pour éviter toute interruption de service, effectuez cette opération pendant les heures creuses.

Étape 4 : Créer un slot de réplication logique

1. Utilisez le compte db_admin pour vous connecter à l'instance ApsaraDB RDS for PostgreSQL.

   psql -h <endpoint of the ApsaraDB RDS for PostgreSQL instance> -p 5432 -U db_admin -d testdb

2. Exécutez la commande suivante pour créer un slot de réplication nommé cdc_replication_slot à l'aide du plugin de sortie test_decoding :

   SELECT pg_create_logical_replication_slot('cdc_replication_slot', 'test_decoding');

   Remarque

   • Le nom du slot cdc_replication_slot est utilisé à titre d'exemple. Vous pouvez spécifier un nom personnalisé.

   • PostgreSQL fournit nativement le plugin de sortie test_decoding ; aucune modification n'est donc requise.

   Exemple de sortie :

    pg_create_logical_replication_slot
   ------------------------------------
    (cdc_replication_slot,1/14003428)
   (1 row)

   Vérifiez si le slot a été créé en exécutant la commande suivante :

   SELECT * FROM pg_replication_slots;

   Exemple de sortie :

         slot_name       |    plugin     | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size  | two_phase
   ----------------------+---------------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+----------------+-----------
    cdc_replication_slot | test_decoding | logical   |  18822 | testdb   | f         | f      |            |      |        22356 | 1/140033F0  | 1/14003428          | reserved   |                | f
   (1 row)

Étape 5 : Créer des données de test

CREATE TABLE public.tb_test(
    id int NOT NULL PRIMARY KEY
);
ALTER TABLE public.tb_test ADD name varchar(1) NULL;
INSERT INTO public.tb_test SELECT 1, 'A';

Étape 6 : Lire les données depuis le slot

1. Utilisez le compte cdc_user pour vous connecter à l'instance ApsaraDB RDS for PostgreSQL.

   psql -h <endpoint of the ApsaraDB RDS for PostgreSQL instance> -p 5432 -U cdc_user -d testdb

2. Exécutez la commande suivante pour lire les modifications depuis le slot de réplication :

   SELECT * FROM pg_logical_slot_peek_changes('cdc_replication_slot', null, null);

   Exemple de sortie :

       lsn     |  xid  |                                  data
   ------------+-------+-------------------------------------------------------------------------
    1/14003D90 | 22376 | BEGIN 22376
    1/1401DDE8 | 22376 | COMMIT 22376
    1/1401DDE8 | 22377 | BEGIN 22377
    1/1401E100 | 22377 | COMMIT 22377
    1/1401E2A8 | 22382 | BEGIN 22382
    1/1401E2A8 | 22382 | table public.tb_test: INSERT: id[integer]:1 name[character varying]:'A'
    1/1401E3C0 | 22382 | COMMIT 22382
   (7 rows)

Étape 7 : Consommer les modifications de données

1. Exécutez la commande \q pour quitter la connexion à la base de données.

2. Exécutez la commande suivante pour consommer les modifications de données :

   Remarque

   Vous devez exécuter la commande pg_recvlogical en tant qu'utilisateur postgres. Vous pouvez changer d'utilisateur en exécutant la commande su - postgres. Si vous rencontrez l'erreur -bash: pg_recvlogical: command not found, consultez la section FAQ pour obtenir une solution.

   pg_recvlogical -h <endpoint of the ApsaraDB RDS for PostgreSQL instance> -U <privileged account> -d <test database> --create-slot --if-not-exists --slot=cdc_replication_slot --plugin=test_decoding --start -f -

   Exemple de commande :

   pg_recvlogical -h pgm-*****.pgsql.singapore.rds.aliyuncs.com -U db_admin -d testdb --create-slot --if-not-exists --slot=cdc_replication_slot --plugin=test_decoding --start -f -

   Exemple de sortie :

   BEGIN 22376
   COMMIT 22376
   BEGIN 22377
   COMMIT 22377
   BEGIN 22382
   table public.tb_test: INSERT: id[integer]:1 name[character varying]:'A'
   COMMIT 22382

Désactiver le CDC

Si la consommation de données est anormale ou s'arrête, les journaux WAL peuvent s'accumuler et saturer tout l'espace disque disponible, ce qui finit par verrouiller l'instance. Pour résoudre ce problème, supprimez manuellement les slots de réplication inactifs, ce qui permet au noyau PostgreSQL de nettoyer les anciens journaux WAL.

FAQ

• Q : Que faire si j'obtiens l'erreur -bash: pg_recvlogical: command not found lors de la consommation des données ?

  R : pg_recvlogical est un outil natif de décodage logique pour PostgreSQL qui utilise le plugin de sortie par défaut test_decoding. Ce plugin se trouve dans le répertoire contrib/test_decoding du package source de PostgreSQL. Compilez et installez PostgreSQL à partir de son code source. Après l'installation, l'outil pg_recvlogical se trouve dans le répertoire /bin du chemin d'installation du client. Pour plus d'informations sur l'installation de PostgreSQL à partir du code source, consultez la page Installation from Source Code.

• Q : J'ai supprimé manuellement un slot de réplication, mais le système n'a pas nettoyé automatiquement les journaux WAL qui continuent d'occuper de l'espace disque. Que faire ?

  R : Définissez le paramètre wal_keep_segments sur sa valeur par défaut de 128 pour réduire le nombre de fichiers journaux conservés. Pour plus d'informations sur la modification des paramètres de l'instance, consultez la page Modifier les paramètres d'une instance ApsaraDB RDS for PostgreSQL.