Utilisation de la réplication logique PostgreSQL avec Aurora - Amazon Aurora
Configuration de la réplication logiqueDésactivation de la réplication logiqueSurveillance du cache d'écriture simultanée de la réplication logiqueGestion des emplacements logiques Exemple : utilisation de la réplication logique Exemple : réplication logique avec Aurora PostgreSQL et AWS DMS

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 la réplication logique PostgreSQL avec Aurora

En utilisant la fonction de réplication logique de PostgreSQL avec votre cluster de bases de données Aurora PostgreSQL, vous pouvez répliquer et synchroniser des tables individuelles plutôt que l'ensemble de l'instance de base de données. La réplication logique s'appuie sur un modèle publier et s'abonner pour répliquer les modifications depuis la source vers un ou plusieurs destinataires. Elle s'appuie sur les enregistrements de modification depuis le journal d'écriture anticipée (WAL) de PostgreSQL. La source, ou l'éditeur, envoie les données WAL pour les tables spécifiées à un ou plusieurs destinataires (abonné), répliquant ainsi les modifications et maintenant la table d'un abonné synchronisée avec la table de l'éditeur. L'ensemble des modifications apportées par l'éditeur est identifié à l'aide d'une publication. Les abonnés obtiennent les modifications en créant un abonnement qui définit la connexion à la base de données de l'éditeur et à ses publications. Un emplacement de réplication est le mécanisme utilisé dans ce schéma pour suivre la progression d'un abonnement.

Pour les clusters de bases de données Aurora PostgreSQL, les enregistrements WAL sont enregistrés sur le stockage Aurora. Le cluster de bases de données Aurora PostgreSQL qui joue le rôle d'éditeur dans un scénario de réplication logique lit les données WAL du stockage Aurora, les décode et les envoie à l'abonné afin que les modifications puissent être appliquées à la table de cette instance. L'éditeur utilise un décodeur logique pour décoder les données destinées aux abonnés. Par défaut, les clusters de bases de données Aurora PostgreSQL utilisent le plug-in pgoutput PostgreSQL natif lors de l'envoi de données. D'autres décodeurs logiques sont disponibles. Par exemple, Aurora PostgreSQL prend également en charge le plug-in wal2json qui convertit les données WAL en JSON.

Depuis Aurora PostgreSQL version 14.5, 13.8, 12.12, et 11.17, Aurora PostgreSQL augmente le processus de réplication logique de PostgreSQL avec un cache à écriture simultanée pour améliorer les performances. Les journaux de transactions WAL sont mis en cache localement, dans une mémoire tampon, afin de réduire la quantité d'entrées/sorties sur disque, c'est-à-dire la lecture du stockage Aurora pendant le décodage logique. Le cache à écriture simultanée est utilisé par défaut lorsque vous utilisez la réplication logique pour votre cluster de bases de données Aurora PostgreSQL. Aurora fournit plusieurs fonctions que vous pouvez utiliser pour gérer le cache. Pour plus d'informations, consultez Gestion du cache d'écriture simultanée de la réplication logique d'Aurora PostgreSQL.

La réplication logique est prise en charge par toutes les versions actuellement disponibles d'Aurora PostgreSQL. Pour plus d'informations, consultez Mises à jour d'Amazon Aurora PostgreSQL dans les Notes de mise à jour d'Aurora PostgreSQL.

Note

Outre la fonctionnalité de réplication logique native de PostgreSQL introduite dans PostgreSQL 10, Aurora PostgreSQL prend également en charge l'extension pglogical. Pour plus d'informations, consultez Utilisation de pglogical pour synchroniser les données entre les instances.

Pour plus d'informations sur la réplication logique PostgreSQL, consultez Réplication logique et Concepts de décodage logique dans la documentation PostgreSQL.

Les rubriques suivantes fournissent des informations sur la façon de configurer la réplication logique entre vos clusters de bases de données Aurora PostgreSQL.

Configuration de la réplication logique pour votre cluster de bases de données Aurora PostgreSQL

La configuration de la réplication logique nécessite des privilèges rds_superuser. Votre cluster de bases de données Aurora PostgreSQL doit être configuré pour utiliser un groupe de paramètres de cluster de bases de données personnalisé afin que vous puissiez définir les paramètres nécessaires comme indiqué dans la procédure suivante. Pour plus d'informations, consultez Utilisation des groupes de paramètres de clusters de base de données.

Configurer la réplication logique PostgreSQL pour votre cluster de bases de données Aurora PostgreSQL

  1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

  2. Dans le volet de navigation, choisissez votre cluster de bases de données Aurora PostgreSQL.

  3. Ouvrez l'onglet Configuration. Parmi les détails de l'instance, recherchez le lien Groupe de paramètres avec Groupe de paramètres de cluster DB comme Type.

  4. Cliquez sur le lien pour ouvrir les paramètres personnalisés associés à votre cluster de bases de données Aurora PostgreSQL.

  5. Dans le champ de recherche Parameters (Paramètres), tapez rds pour trouver le paramètre rds.logical_replication. La valeur par défaut de ce paramètre est 0, ce qui signifie qu'il est désactivé par défaut.

  6. Choisissez Edit parameters (Modifier les paramètres) pour accéder aux valeurs des propriétés, puis choisissez 1 dans le sélecteur pour activer la fonction. En fonction de votre utilisation prévue, vous devrez peut-être également modifier les paramètres suivants. Toutefois, dans de nombreux cas, les valeurs par défaut sont suffisantes.

    • max_replication_slots – Définissez ce paramètre sur une valeur au moins égale au nombre total prévu de publications et d'abonnements de réplication logique. Si vous utilisez AWS DMS, ce paramètre doit être au moins égal à vos tâches de capture de données de modification planifiées à partir du cluster, plus les publications de réplication logique et les abonnements.

    • max_wal_senders et max_logical_replication_workers – Définissez ces paramètres sur une valeur au moins égale au nombre d'emplacements de réplication logique qui devraient être actifs ou le nombre de tâches AWS DMS actives pour la capture des données de modification. Le fait de laisser un emplacement de réplication logique inactif empêche le vacuum de supprimer les tuples obsolètes des tables. Nous vous recommandons donc de surveiller les emplacements de réplication et de supprimer les emplacements inactifs, le cas échéant.

    • max_worker_processes – Définissez ce paramètre sur une valeur au moins égale au total des valeurs max_logical_replication_workers, autovacuum_max_workers et max_parallel_workers. Les processus d'employés en arrière-plan peuvent affecter les charges de travail des applications sur les petites classes d'instances de base de données. Surveillez les performances de votre base de données si vous définissez max_worker_processes sur une valeur supérieure à la valeur par défaut. (La valeur par défaut est le résultat de GREATEST(${DBInstanceVCPU*2},8}, ce qui signifie que, par défaut, c'est huit ou deux fois l'équivalent CPU de la classe d'instance de base de données, selon la valeur la plus élevée).

    Note

    Vous pouvez modifier des valeurs de paramètres dans un groupe de paramètres de base de données créé par le client. Vous ne pouvez pas modifier les valeurs de paramètres dans un groupe de paramètres de base de données par défaut.

  7. Sélectionnez Enregistrer les modifications.

  8. Redémarrez l'instance d'écriture de votre cluster de bases de données Aurora PostgreSQL afin que vos modifications prennent effet. Dans la console Amazon RDS, choisissez l'instance de base de données principale du cluster et choisissez Reboot (Redémarrer) dans le menu Actions.

  9. Lorsque l'instance est disponible, vous pouvez vérifier que la réplication logique est activée, comme suit.

    1. Utilisez psql pour vous connecter à l'instance d'écriture de votre cluster de bases de données Aurora PostgreSQL.

      psql --host=your-db-cluster-instance-1.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb

    2. Vérifiez que la réplication logique a été activée à l'aide de la commande suivante.

      labdb=> SHOW rds.logical_replication;
 rds.logical_replication
-------------------------
 on
(1 row)

    3. Vérifiez que wal_level est défini sur logical. 

      labdb=> SHOW wal_level;
  wal_level
-----------
 logical
(1 row)

Pour un exemple d'utilisation de la réplication logique pour maintenir une table de base de données synchronisée avec les modifications provenant d'un cluster de bases de données Aurora PostgreSQL source, consultez Exemple : utilisation de la réplication logique avec les clusters de bases de données Aurora PostgreSQL.

Désactivation de la réplication logique

Une fois vos tâches de réplication terminées, vous devez arrêter le processus de réplication, supprimer les emplacements de réplication et désactiver la réplication logique. Avant de supprimer des emplacements, assurez-vous qu'ils ne sont plus nécessaires. Les emplacements de réplication actifs ne peuvent pas être supprimés.

Désactiver la réplication logique

  1. Supprimez tous les emplacements de réplication.

    Pour supprimer tous les emplacements de réplication, connectez-vous à l'éditeur et exécutez la commande SQL suivante.

    SELECT pg_drop_replication_slot(slot_name)
  FROM pg_replication_slots
 WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);

    Les emplacements de réplication ne peuvent pas être actifs lorsque vous exécutez cette commande.

  2. Modifiez le groupe de paramètres personnalisé du cluster de bases de données associé à l'éditeur, comme indiqué dans Configuration de la réplication logique pour votre cluster de bases de données Aurora PostgreSQL, mais définissez le paramètre rds.logical_replication sur 0.

    Pour obtenir plus d'informations sur les groupes de paramètres personnalisés, consultez Modification de paramètres dans un groupe de paramètres de cluster de base de données.

  3. Redémarrez le cluster de bases de données Aurora PostgreSQL de l'éditeur pour que les modifications apportées au paramètre rds.logical_replication s'appliquent.

Gestion du cache d'écriture simultanée de la réplication logique d'Aurora PostgreSQL

Par défaut, Aurora PostgreSQL versions 14.5, 13.8, 12.12, et 11.17 et suivantes utilisent un cache à écriture simultanée pour améliorer les performances de la réplication logique. Sans le cache à écriture simultanée, Aurora PostgreSQL utilise la couche de stockage Aurora dans sa mise en œuvre du processus de réplication logique natif de PostgreSQL. Pour ce faire, il écrit des données WAL sur un support de stockage, puis lit les données sur ce support pour les décoder et les envoyer (répliquer) à ses cibles (abonnés). Cela peut entraîner des goulots d'étranglement pendant la réplication logique pour les clusters de bases de données Aurora PostgreSQL.

Le cache à écriture simultanée réduit la nécessité d'utiliser la couche de stockage Aurora. Au lieu de toujours écrire et lire à partir de la couche de stockage d'Aurora, Aurora PostgreSQL utilise un tampon pour mettre en cache le flux WAL logique afin qu'il puisse être utilisé pendant le processus de réplication, plutôt que de toujours extraire du disque. Ce tampon est le cache natif de PostgreSQL utilisé par la réplication logique, identifié dans les paramètres du cluster de bases de données Aurora PostgreSQL comme rds.logical_wal_cache. Par défaut, ce cache utilise 1/32 du paramètre de cache tampon du cluster de bases de données Aurora PostgreSQL (shared_buffers) mais pas moins de 64 Ko ni plus que la taille d'un segment WAL, généralement 16 Mo.

Lorsque vous utilisez la réplication logique avec votre cluster de bases de données Aurora PostgreSQL (pour les versions qui prennent en charge le cache en écriture simultanée), vous pouvez surveiller le taux de réussite de la mise en cache pour voir si elle fonctionne bien pour votre cas d'utilisation. Pour ce faire, connectez-vous à l'instance en écriture de votre cluster de bases de données Aurora PostgreSQL à l'aide de psql et utilisez ensuite la fonction Aurora, aurora_stat_logical_wal_cache, comme indiqué dans l'exemple suivant.

SELECT * FROM aurora_stat_logical_wal_cache();

La fonction renvoie la sortie suivante.

name       | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
-----------+------------+-----------+------------+-----------+----------+--------------
test_slot1 | 79183      | 24        | 0          | 24        | 100.00%  | 2022-08-05 17:39...
test_slot2 |            | 1         | 0          |  1        | 100.00%  | 2022-08-05 17:34...
(2 rows)

Les valeurs last_reset_timestamp ont été raccourcies pour plus de lisibilité. Pour de plus amples informations sur cette fonction, veuillez consulter aurora_stat_logical_wal_cache.

Aurora PostgreSQL fournit les deux fonctions suivantes pour surveiller le cache à écriture simultanée.

Si vous trouvez que la taille du cache WAL ajustée automatiquement n'est pas suffisante pour vos charges de travail, vous pouvez changer la valeur de rds.logical_wal_cache manuellement, en modifiant le paramètre dans votre groupe de paramètres de cluster de bases de données personnalisé. Notez que toute valeur positive inférieure à 32 Ko est traitée comme faisant 32 Ko. Pour plus d'informations sur wal_buffers, consultez Write Ahead Log (Journal d'écriture anticipée) dans la documentation PostgreSQL.

Gestion des emplacements logiques pour Aurora PostgreSQL

L'activité de streaming est capturée dans la vue pg_replication_origin_status. Pour voir le contenu de cette vue, vous pouvez utiliser la fonction pg_show_replication_origin_status(), comme indiqué ci-dessous :

SELECT * FROM pg_show_replication_origin_status();

Vous pouvez obtenir la liste de vos emplacements logiques à l'aide de la requête SQL suivante.

SELECT * FROM pg_replication_slots;

Pour supprimer un emplacement logique, utilisez pg_drop_replication_slot avec le nom de l'option, comme indiqué dans la commande suivante.

SELECT pg_drop_replication_slot('test_slot');

Exemple : utilisation de la réplication logique avec les clusters de bases de données Aurora PostgreSQL

La procédure suivante vous indique comment démarrer la réplication logique entre deux clusters de bases de données Aurora PostgreSQL. L'éditeur et l'abonné doivent être configurés pour la réplication logique, comme indiqué dans Configuration de la réplication logique pour votre cluster de bases de données Aurora PostgreSQL.

Le cluster de bases de données Aurora PostgreSQL qui est l'éditeur désigné doit également autoriser l'accès à l'emplacement de réplication. Pour ce faire, modifiez le groupe de sécurité associé au cloud privé virtuel (VPC) du cluster de bases de données Aurora PostgreSQL basé sur le service Amazon VPC. Autorisez l'accès entrant en ajoutant le groupe de sécurité associé au VPC de l'abonné au groupe de sécurité de l'éditeur. Pour plus d'informations, consultez la rubrique Contrôler le trafic vers les ressources à l'aide de groupes de sécurité dans le Guide de l'utilisateur Amazon Virtual Private Cloud.

Une fois ces étapes préliminaires terminées, vous pouvez utiliser les commandes PostgreSQL CREATE PUBLICATION sur le serveur de publication et CREATE SUBSCRIPTION sur l'abonné, comme indiqué dans la procédure suivante.

Démarrer le processus de réplication logique entre deux clusters de bases de données Aurora PostgreSQL

Ces étapes supposent que vos clusters de bases de données Aurora PostgreSQL disposent d'une instance d'écriture avec une base de données dans laquelle créer les tables d'exemple.

  1. Sur le cluster de bases de données Aurora PostgreSQL de l'éditeur

    1. Créez une table en utilisant l'instruction SQL suivante.

      CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);

    2. Insérez les données dans la base de données éditeur à l'aide de l'instruction SQL suivante.

      INSERT INTO LogicalReplicationTest VALUES (generate_series(1,10000));

    3. Vérifiez que les données existent dans la table à l'aide de l'instruction SQL suivante.

      SELECT count(*) FROM LogicalReplicationTest;

    4. Créez une publication pour cette table à l'aide de l'instruction CREATE PUBLICATION, comme suit.

      CREATE PUBLICATION testpub FOR TABLE LogicalReplicationTest;

  2. Sur le cluster de bases de données Aurora PostgreSQL de l'abonné

    1. Créez la même table LogicalReplicationTest sur l'abonné que celle que vous avez créée sur l'éditeur, comme suit.

      CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);

    2. Vérifiez que cette table est vide.

      SELECT count(*) FROM LogicalReplicationTest;

    3. Créez un abonnement pour obtenir les modifications de la part de l'éditeur. Vous devez utiliser les informations suivantes concernant le cluster de bases de données Aurora PostgreSQL de l'éditeur.

      • host – Instance de base de données en écriture du cluster de bases de données Aurora PostgreSQL de l'éditeur.

      • port – Port sur lequel l'instance de base de données écoute. La valeur par défaut pour PostgreSQL est 5432.

      • dbname – Nom de la base de données.

      CREATE SUBSCRIPTION testsub CONNECTION 
   'host=publisher-cluster-writer-endpoint port=5432 dbname=db-name user=user password=password' 
   PUBLICATION testpub;
      Note

      Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité.

      Une fois que l'abonnement est créé, un emplacement de réplication logique est créé chez l'éditeur.

    4. Pour vérifier dans cet exemple que les données initiales sont répliquées sur l'abonné, utilisez l'instruction SQL suivante sur la base de données abonné.

      SELECT count(*) FROM LogicalReplicationTest;

Toute modification ultérieure sur l'éditeur sera répliquée sur l'abonné.

La réplication logique affecte les performances. Nous vous recommandons de désactiver la réplication logique une fois vos tâches de réplication terminées.

Exemple : réplication logique avec Aurora PostgreSQL et AWS Database Migration Service

Vous pouvez utiliser AWS Database Migration Service (AWS DMS) pour répliquer une base de données ou une partie d'une base de données. Utilisez AWS DMS pour migrer vos données d'une base de données Aurora PostgreSQL vers une autre base de données open source ou commerciale. Pour plus d'informations sur AWS DMS, consultez le Guide de l'utilisateur AWS Database Migration Service.

L'exemple suivant montre comment configurer la réplication logique à partir d'une base de données Aurora PostgreSQL comme éditeur, puis utiliser AWS DMS pour la migration. Cet exemple utilise les mêmes éditeur et abonné que ceux créés dans Exemple : utilisation de la réplication logique avec les clusters de bases de données Aurora PostgreSQL.

Pour configurer la réplication logique avec AWS DMS, vous avez besoin d'informations d'Amazon RDS sur votre éditeur et votre abonné. En particulier, vous avez besoin d'informations sur l'instance de base de données en écriture de l'éditeur et l'instance de base de données de l'abonné.

Obtenez les informations suivantes pour l'instance de base de données en écriture de l'éditeur :

  • Identifiant VPC (Virtual Private Cloud)

  • Groupe de sous-réseaux

  • Zone de disponibilité

  • Groupe de sécurité VPC

  • ID de l'instance de base de données

Obtenez les informations suivantes pour l'instance de base de données de l'abonné :

  • ID de l'instance de base de données

  • Moteur source

Pour utiliser AWS DMS pour la réplication logique avec Aurora PostgreSQL

  1. Préparez la base de données éditeur pour qu'elle fonctionne avec AWS DMS.

    À cette fin, PostgreSQL 10.x et les bases de données ultérieures nécessitent que vous appliquiez les fonctions wrapper AWS DMS à la base de données éditeur. Pour plus d'informations sur cette étape et les étapes ultérieures, consultez les instructions dans Utilisation de PostgreSQL version 10.x et version ultérieure comme source pour AWS DMS dans le Guide de l'utilisateur AWS Database Migration Service.

  2. Connectez-vous à AWS Management Console et ouvrez la console AWS DMS à l'adresse https://console.aws.amazon.com/dms/v2. En haut à droite, sélectionnez la région AWS où se trouvent l'éditeur et l'abonné.

  3. Créez une instance de réplication AWS DMS.

    Choisissez des valeurs identiques à celles de l'instance de base de données en écriture de votre éditeur. Tel est le cas des éléments suivants :

    • Pour VPC, choisissez le même VPC que pour l'instance de base de données en écriture.

    • Pour Replication Subnet Group (Groupe de sous-réseaux de réplication), choisissez un groupe de sous-réseaux possédant les mêmes valeurs que celui de l'instance de base de données en écriture. Créez-en un nouveau si nécessaire.

    • Pour Availability zone (Zone de disponibilité), choisissez la même zone que celle de l'instance de base de données en écriture.

    • Pour VPC Security Group (Groupe de sécurité VPC), choisissez le même groupe que celui de l'instance de base de données en écriture.

  4. Créez un point de terminaison AWS DMS pour la source.

    Spécifiez l'éditeur comme point de terminaison source à l'aide des paramètres suivants :

    • Pour Endpoint type (Type de point de terminaison), choisissez Source endpoint (Point de terminaison source).

    • Choisissez Select RDS DB Instance (Sélectionner une instance de base de données RDS).

    • Pour RDS Instance (Instance RDS), choisissez l'ID de base de données de l'instance de base de données en écriture de l'éditeur.

    • Pour Source engine (Moteur source), choisissez postgres.

  5. Créez un point de terminaison AWS DMS pour la cible.

    Spécifiez l'éditeur comme point de terminaison cible à l'aide des paramètres suivants :

    • Pour Endpoint type (Type de point de terminaison), choisissez Target endpoint (Point de terminaison cible).

    • Choisissez Select RDS DB Instance (Sélectionner une instance de base de données RDS).

    • Pour RDS Instance (Instance RDS), choisissez l'ID de base de données de l'instance de base de données de l'abonné.

    • Choisissez une valeur pour Source engine (Moteur source). Par exemple, si l'abonné est une base de données RDS PostgreSQL, choisissez postgres. Si l'abonné est une base de données Aurora PostgreSQL, choisissez aurora-postgresql.

  6. Créez une tâche de migration de base de données AWS DMS.

    Vous utilisez une tâche de migration de base de données pour spécifier les tables à migrer, pour mapper les données à l'aide d'un schéma cible et pour créer des tables sur la base de données cible. À tout le moins, utilisez les paramètres suivants pour Task configuration (Configuration de la tâche) :

    • Pour Replication instance (Instance de réplication), choisissez l'instance de réplication que vous avez créée à une étape précédente.

    • Pour Source database endpoint (Point de terminaison de la base de données source), choisissez l'éditeur source que vous avez créé à une étape précédente.

    • Pour Target database endpoint (Point de terminaison de la base de données cible), choisissez l'abonné cible que vous avez créé lors d'une étape précédente.

    Le reste des détails de la tâche dépend de votre projet de migration. Pour plus d'informations sur la spécification de tous les détails pour les tâches DMS, consultez Utilisation des tâches AWS DMS dans le Guide de l'utilisateurAWS Database Migration Service.

Une fois que AWS DMS a créé la tâche, il commence la migration des données entre l'éditeur et l'abonné.