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.
# Réplication avec Amazon Aurora PostgreSQL
Vous trouverez ci-dessous des informations sur la réplication avec Amazon Aurora PostgreSQL, notamment sur la manière de surveiller et d’utiliser la réplication.
**Topics**
+ [Utilisation de réplicas Aurora](#AuroraPostgreSQL.Replication.Replicas)
+ [Amélioration de la disponibilité en lecture des réplicas Aurora](#AuroraPostgreSQL.Replication.Replicas.SRO)
+ [Surveillance de la réplication Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Monitoring)
+ [Présentation de la réplication logique PostgreSQL avec Aurora](AuroraPostgreSQL.Replication.Logical.md)
+ [Configuration de la réplication logique pour votre cluster de bases de données Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.Configure.md)
+ [Désactivation de la réplication logique](AuroraPostgreSQL.Replication.Logical.Stop.md)
+ [Surveillance du cache à écriture simultanée et des emplacements logiques pour la réplication logique Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md)
+ [Exemple : utilisation de la réplication logique avec les clusters de bases de données Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md)
+ [Exemple : réplication logique à l'aide d'Aurora PostgreSQL et AWS Database Migration Service](AuroraPostgreSQL.Replication.Logical.DMS-Example.md)
+ [Configuration de l'authentification IAM pour les connexions de réplication logiques](AuroraPostgreSQL.Replication.Logical.IAM-auth.md)
## Utilisation de réplicas Aurora
Les *réplicas Aurora* sont les points de terminaison indépendants d’un cluster de bases de données Aurora, utilisés de préférence pour la mise à l’échelle des opérations de lecture et l’augmentation de la disponibilité. Un cluster de base de données Aurora peut inclure jusqu'à 15 répliques Aurora situées dans les zones de disponibilité de la AWS région du cluster de base de données Aurora.
Le volume de cluster de bases de données est composé de plusieurs copies des données du cluster de bases de données. Cependant, les données du volume de cluster sont représentées comme un seul volume logique à l’instance principale en écriture et aux réplicas Aurora du cluster de bases de données. Pour plus d’informations sur les réplicas Aurora, consultez [Réplicas Aurora](Aurora.Replication.md#Aurora.Replication.Replicas).
Les réplicas Aurora fonctionnement parfaitement pour le dimensionnement en lecture, car ils sont intégralement dédiés aux opérations de lecture du volume de votre cluster. L’instance de base de données en écriture gère les opérations d’écriture. Le volume du cluster est partagé entre toutes les instances de votre cluster de bases de données Aurora PostgreSQL. Ainsi, aucun travail supplémentaire n’est nécessaire pour répliquer une copie des données pour chaque réplica Aurora.
Avec Aurora PostgreSQL, quand un réplica Aurora est supprimé, le point de terminaison de son instance est supprimé immédiatement et le réplica Aurora est supprimé du point de terminaison du lecteur. S’il y a des instructions qui s’exécutent sur le réplica Aurora en cours de suppression, une période de grâce de trois minutes est accordée. Les instructions existantes peuvent se terminer élégamment pendant la période de grâce. Lorsque la période de grâce se termine, le réplica Aurora est arrêté et supprimé.
Les clusters de base de données Aurora PostgreSQL prennent en charge les répliques Aurora dans AWS différentes régions, en utilisant la base de données globale Aurora. Pour de plus amples informations, veuillez consulter [Utilisation d’Amazon Aurora Global Database](aurora-global-database.md).
**Note**
Avec la fonctionnalité de disponibilité en lecture, si vous voulez redémarrer les réplicas Aurora dans le cluster de bases de données, vous devez le faire manuellement. Pour les clusters de bases de données créés avant cette fonction, le redémarrage de l’instance de base de données d’écriture redémarre automatiquement les réplicas Aurora. Le redémarrage automatique rétablit un point d'entrée qui garantit la read/write cohérence au sein du cluster de base de données.
## Amélioration de la disponibilité en lecture des réplicas Aurora
Aurora PostgreSQL améliore la disponibilité en lecture dans le cluster de bases de données en répondant en continu aux demandes de lecture lorsque l’instance de base de données d’écriture redémarre ou lorsque le réplica Aurora n’est pas en mesure de suivre le trafic d’écriture.
La fonction de disponibilité en lecture est disponible par défaut sur les versions suivantes d’Aurora PostgreSQL :
+ 16.1 et toutes les versions ultérieures
+ 15.2 et versions 15 ultérieures
+ 14.7 et versions 14 ultérieures
+ 13.10 et versions 13 ultérieures
+ 12.14 et versions 12 ultérieures
La fonction de disponibilité en lecture est prise en charge par la base de données globale Aurora dans les versions suivantes :
+ 16.1 et toutes les versions ultérieures
+ 15.4 et versions 15 ultérieures
+ 14.9 et versions 14 ultérieures
+ 13.12 et versions 13 ultérieures
+ 12.16 et versions 12 ultérieures
Pour utiliser la fonction de disponibilité en lecture pour un cluster de bases de données créé sur l’une de ces versions avant ce lancement, redémarrez l’instance d’enregistreur du cluster de bases de données.
Lorsque vous modifiez les paramètres statiques de votre cluster de bases de données Aurora PostgreSQL, vous devez redémarrer l’instance d’enregistreur pour que les modifications des paramètres soient prises en compte. Par exemple, vous devez redémarrer l’instance d’enregistreur lorsque vous définissez la valeur de `shared_buffers`. Grâce à la fonctionnalité de disponibilité en lecture des réplicas Aurora, le cluster de bases de données assure une disponibilité améliorée, ce qui réduit l’impact dont il fait l’objet lorsque l’instance d’enregistreur redémarre. Les instances de lecture ne redémarrent pas et continuent de répondre aux demandes de lecture. Pour appliquer les modifications de paramètres statiques, redémarrez chaque instance de lecteur individuelle.
Le réplica Aurora d’un cluster de bases de données Aurora PostgreSQL peut remédier à des erreurs de réplication telles que le redémarrage de l’enregistreur, le basculement, la lenteur de la réplication et les problèmes de réseau en rétablissant rapidement l’état de la base de données en mémoire après la reconnexion avec l’enregistreur. Cette approche permet aux instances des réplicas Aurora d’être cohérentes avec les dernières mises à jour de stockage alors que la base de données client est toujours disponible.
Les transactions en cours qui entrent en conflit avec la restauration de la réplication peuvent recevoir une erreur, mais le client peut réessayer ces transactions une fois que les lecteurs s’alignent sur l’enregistreur.
### Surveillance des réplicas Aurora
Vous pouvez surveiller les réplicas Aurora lors d’une récupération suite à une déconnexion de l’enregistreur. Utilisez les métriques ci-dessous pour vérifier les informations les plus récentes concernant l’instance de lecteur et pour suivre les transactions en lecture seule en cours de traitement.
+ La `aurora_replica_status` fonction est mise à jour pour renvoyer le maximum up-to-date d'informations pour l'instance de lecteur lorsqu'elle est toujours connectée. L’horodatage de la dernière mise à jour dans `aurora_replica_status` est toujours vide pour la ligne correspondant à l’instance de base de données sur laquelle la requête est exécutée. Cela indique que l’instance de lecteur possède les données les plus récentes.
+ Lorsque le réplica Aurora se déconnecte de l’instance d’enregistreur, puis se reconnecte, l’événement de base de données suivant est émis :
`Read replica has been disconnected from the writer instance and reconnected.`
+ Lorsqu’une requête en lecture seule est annulée en raison d’un conflit de récupération, vous pouvez voir un ou plusieurs des messages d’erreur suivants dans le journal des erreurs de la base de données :
`Canceling statement due to conflict with recovery`.
`User query may not have access to page data to replica disconnect.`
`User query might have tried to access a file that no longer exists.`
`When the replica reconnects, you will be able to repeat your command.`
### Limitations
Les réplicas Aurora avec la fonctionnalité de disponibilité en lecture sont soumis aux limitations suivantes :
+ Les réplicas Aurora du cluster de bases de données secondaire peuvent redémarrer si les données ne peuvent pas être diffusées depuis l’instance d’enregistreur pendant la restauration de la réplication.
+ Les réplicas Aurora ne prennent pas en charge la récupération de la réplication en ligne si celle-ci est déjà en cours et doit redémarrer.
+ Les réplicas Aurora redémarrent quand votre instance de base de données approche du bouclage de l’ID de transaction. Pour plus d’informations sur le bouclage de l’ID de transaction, consultez [Prévention des échecs de bouclage de l’ID de transaction](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND ).
+ Les réplicas Aurora peuvent redémarrer lorsque le processus de réplication est bloqué dans certaines circonstances.
## Surveillance de la réplication Aurora PostgreSQL
Le dimensionnement en lecture et la haute disponibilité dépendent d’un temps de retard minimal. Vous pouvez surveiller le retard d'une réplique Aurora par rapport à l'instance de base de données Writer de votre cluster de bases de données Aurora PostgreSQL en surveillant la métrique Amazon. CloudWatch `ReplicaLag` Comme les réplicas Aurora lisent à partir du même volume de cluster que l’instance de base de données en écriture, la métrique `ReplicaLag` a une signification différente pour un cluster de bases de données Aurora PostgreSQL. La métrique `ReplicaLag` d’un réplica Aurora indique le retard du cache de page du réplica Aurora par rapport à celui de l’instance de base de données en écriture.
Pour plus d'informations sur la surveillance des instances et des CloudWatch métriques RDS, consultez[Surveillance des métriques d’un cluster de bases de données Amazon Aurora](MonitoringAurora.md).
# Présentation 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](https://github.com/eulerto/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 [Surveillance du cache à écriture simultanée de la réplication logique Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache).
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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) dans *Notes de mise à jour d’Aurora PostgreSQL*.
La réplication logique est prise en charge par Babelfish pour Aurora PostgreSQL à partir des versions suivantes :
+ 15.7 et versions ultérieures
+ 16.3 et versions ultérieures
**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](Appendix.PostgreSQL.CommonDBATasks.pglogical.md).
Pour plus d’informations sur la réplication logique PostgreSQL, consultez [Réplication logique](https://www.postgresql.org/docs/current/logical-replication.html) et [Concepts de décodage logique](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html) dans la documentation PostgreSQL.
**Note**
PostgreSQL 16 a ajouté la prise en charge du décodage logique à partir de répliques de lecture. Cette fonctionnalité n'est pas prise en charge sur 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 [Groupes de paramètres de cluster de bases de données pour les clusters de bases de données Amazon Aurora](USER_WorkingWithDBClusterParamGroups.md).
**Configurer la réplication logique PostgreSQL pour votre cluster de bases de données Aurora PostgreSQL**
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 votre cluster de bases de données Aurora PostgreSQL.
1. 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**.
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 `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.
1. 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 au moins être égal à vos tâches de capture des données de modification planifiées à partir du cluster, ainsi qu'aux publications et abonnements de réplication logique.
+ `max_wal_senders`et `max_logical_replication_workers` — Définissez ces paramètres sur une valeur au moins égale au nombre de slots de réplication logiques que vous souhaitez activer ou au nombre de AWS DMS tâches 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 de travail en arrière-plan peuvent affecter les charges de travail des applications sur les petites classes d’instance 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.
1. Sélectionnez **Enregistrer les modifications**.
1. Redémarrez l’instance d’enregistreur 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**.
1. 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’enregistreur 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
```
1. 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)
```
1. 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](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md).
# 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.
1. 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](AuroraPostgreSQL.Replication.Logical.Configure.md), 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 des paramètres d'un groupe de paramètres de cluster de base de données dans Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
1. 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.
# Surveillance du cache à écriture simultanée et des emplacements logiques pour la réplication logique Aurora PostgreSQL
Surveillez le cache à écriture simultanée de la réplication logique et gérez les emplacements logiques afin d’améliorer les performances de votre cluster de bases de données Aurora PostgreSQL. Vous trouverez ci-dessous des informations supplémentaires sur le cache à écriture simultanée et les emplacements logiques.
**Topics**
+ [Surveillance du cache à écriture simultanée de la réplication logique Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Logical-write-through-cache)
+ [Gestion des emplacements logiques pour Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)
## Surveillance du cache à écriture simultanée de la réplication logique 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 évite de dépendre trop de la couche de stockage Aurora. Au lieu de toujours écrire et lire à partir de cette couche, Aurora PostgreSQL utilise un tampon pour mettre en cache le flux WAL logique à utiliser pendant le processus de réplication, ce qui évite d’avoir à accéder au disque. Ce tampon est le cache PostgreSQL natif utilisé dans la réplication logique. Il est identifié dans les paramètres du cluster de bases de données Aurora PostgreSQL en tant que `rds.logical_wal_cache`.
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 plus d’informations sur cette fonction, consultez [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
Aurora PostgreSQL fournit les deux fonctions suivantes pour surveiller le cache à écriture simultanée.
+ La fonction `aurora_stat_logical_wal_cache` :pour la documentation de référence, consultez [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
+ La fonction `aurora_stat_reset_wal_cache` :pour la documentation de référence, consultez [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md).
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. Éléments à prendre en compte :
+ Lorsque le paramètre `rds.logical_replication` est désactivé, `rds.logical_wal_cache` est défini sur zéro (0).
+ Lorsque le paramètre `rds.logical_replication` est activé, `rds.logical_wal_cache` utilise la valeur par défaut, 16 Mo.
+ Le paramètre `rds.logical_wal_cache` est statique et nécessite un redémarrage de l’instance de base de données pour que les modifications prennent effet. Ce paramètre est défini en termes de blocs de 8 Ko. Notez que toute valeur positive inférieure à 32 Ko est traitée comme équivalant à 32 Ko. Pour plus d’informations sur `wal_buffers`, consultez [Write Ahead Log](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS) 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](AuroraPostgreSQL.Replication.Logical.Configure.md).
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é](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) 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’enregistreur 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);
```
1. 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));
```
1. Vérifiez que les données existent dans la table à l’aide de l’instruction SQL suivante.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. Créez une publication pour cette table à l’aide de l’instruction `CREATE PUBLICATION`, comme suit.
```
CREATE PUBLICATION testpub FOR TABLE LogicalReplicationTest;
```
1. **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);
```
1. Vérifiez que cette table est vide.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. 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.
1. 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 à l'aide d'Aurora PostgreSQL et AWS Database Migration Service
Vous pouvez utiliser le AWS Database Migration Service (AWS DMS) pour répliquer une base de données ou une partie d'une base de données. AWS DMS À utiliser 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 AWS DMS, consultez le [guide de AWS Database Migration Service l'utilisateur](https://docs.aws.amazon.com/dms/latest/userguide/).
L'exemple suivant montre comment configurer une réplication logique à partir d'une base de données Aurora PostgreSQL en tant qu'éditeur, puis AWS DMS comment l'utiliser 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](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md).
Pour configurer la réplication logique avec AWS DMS, vous devez obtenir des informations sur votre éditeur et votre abonné auprès d'Amazon RDS. 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 du cloud privé virtuel (VPC)
+ 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
**À utiliser AWS DMS pour la réplication logique avec Aurora PostgreSQL**
1. Préparez la base de données de l'éditeur à utiliser 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](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10) dans le *Guide de l’utilisateur AWS Database Migration Service *.
1. Connectez-vous à la AWS DMS console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/dms/v2](https://console.aws.amazon.com/dms/v2). En haut à droite, choisissez la même AWS région dans laquelle se trouvent l'éditeur et l'abonné.
1. Créez une instance AWS DMS de réplication.
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.
1. Créez un AWS DMS point de terminaison 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**.
1. Créez un AWS DMS point de terminaison 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**.
1. Créez une tâche AWS DMS de migration de base de données.
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 relatifs aux tâches DMS, voir [Utilisation des tâches AWS DMS dans le Guide](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.html) de l'*AWS Database Migration Service utilisateur*.
Après avoir AWS DMS créé la tâche, elle commence à migrer les données de l'éditeur vers l'abonné.
# Configuration de l'authentification IAM pour les connexions de réplication logiques
À partir des versions 11 et supérieures d'Aurora PostgreSQL, vous pouvez AWS utiliser l'authentification Identity and Access Management (IAM) pour les connexions de réplication. Cette fonctionnalité améliore la sécurité en vous permettant de gérer l'accès à la base de données à l'aide de rôles IAM plutôt que de mots de passe. Elle fonctionne au niveau du cluster et suit le même modèle de sécurité que l'authentification IAM standard.
L'authentification IAM pour les connexions de réplication est une fonctionnalité optionnelle. Pour l'activer, définissez le `rds.iam_auth_for_replication` paramètre sur `1` dans le groupe de paramètres de votre cluster de base de données. Comme il s'agit d'un paramètre dynamique, votre cluster de base de données n'a pas besoin de redémarrer, ce qui vous permet de tirer parti de l'authentification IAM avec les charges de travail existantes sans interruption de service. Avant d'activer cette fonctionnalité, vous devez respecter les conditions [Conditions préalables](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites) répertoriées ci-dessous.
## Conditions préalables
Pour utiliser l'authentification IAM pour les connexions de réplication, vous devez satisfaire à toutes les exigences suivantes :
+ Votre cluster de base de données Aurora PostgreSQL doit être de version 11 ou ultérieure.
+ Sur le cluster de base de données PostgreSQL Aurora de votre éditeur :
+ Activez l'authentification de base de données IAM.
Pour de plus amples informations, veuillez consulter [Activation et désactivation de l’authentification de base de données IAM](UsingWithRDS.IAMDBAuth.Enabling.md).
+ Activez la réplication logique en définissant le `rds.logical_replication` paramètre sur`1`.
Pour de plus amples informations, veuillez consulter [Configuration de la réplication logique pour votre cluster de bases de données Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.Configure.md).
Dans la réplication logique, l'éditeur est le cluster de base de données Aurora PostgreSQL source qui envoie des données aux clusters d'abonnés. Pour plus d'informations, consultez [Présentation de la réplication logique PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.Logical.html) avec Aurora.
**Note**
L'authentification IAM et la réplication logique doivent être activées sur le cluster de base de données PostgreSQL Aurora de votre éditeur. Si l'une ou l'autre n'est pas activée, vous ne pouvez pas utiliser l'authentification IAM pour les connexions de réplication.
## Activation de l'authentification IAM pour les connexions de réplication
Procédez comme suit pour activer l'authentification IAM pour la connexion de réplication.
1. Vérifiez que votre cluster de base de données Aurora PostgreSQL répond à toutes les conditions requises pour l'authentification IAM avec des connexions de réplication. Pour en savoir plus, consultez [Conditions préalables](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites).
1. Configurez le `rds.iam_auth_for_replication` paramètre en modifiant le groupe de paramètres de votre cluster de base de données :
+ Définissez le paramètre `rds.iam_auth_for_replication` sur `1`. Ce paramètre dynamique ne nécessite pas de redémarrage.
1. Connectez-vous à votre base de données et accordez les rôles nécessaires à votre utilisateur de réplication :
Les commandes SQL suivantes octroient les rôles nécessaires pour activer l'authentification IAM pour les connexions de réplication :
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
Après avoir effectué ces étapes, l'utilisateur spécifié doit utiliser l'authentification IAM pour les connexions de réplication.
**Important**
Lorsque vous activez cette fonctionnalité, les utilisateurs possédant à la fois des `rds_replication` rôles `rds_iam` et des rôles doivent utiliser l'authentification IAM pour les connexions de réplication. Cela s'applique que les rôles soient attribués directement à l'utilisateur ou hérités par le biais d'autres rôles.
## Désactivation de l'authentification IAM pour les connexions de réplication
Vous pouvez désactiver l'authentification IAM pour les connexions de réplication en utilisant l'une des méthodes suivantes :
+ Définissez le `rds.iam_auth_for_replication` paramètre sur `0` dans le groupe de paramètres de votre cluster de base de données
+ Vous pouvez également désactiver l'une des fonctionnalités suivantes sur votre cluster de base de données Aurora PostgreSQL :
+ Désactivez la réplication logique en définissant le `rds.logical_replication` paramètre sur `0`
+ Désactiver l'authentification IAM
Lorsque vous désactivez cette fonctionnalité, les connexions de réplication peuvent utiliser les mots de passe de base de données pour l'authentification, si elles sont configurées.
**Note**
Les connexions de réplication pour les utilisateurs n'ayant pas le `rds_iam` rôle peuvent utiliser l'authentification par mot de passe même lorsque la fonctionnalité est activée.
## Limites et considérations
Les limites et considérations suivantes s'appliquent lors de l'utilisation de l'authentification IAM pour les connexions de réplication.
+ L'authentification IAM pour les connexions de réplication n'est disponible que pour les versions 11 et supérieures d'Aurora PostgreSQL.
+ L'éditeur doit prendre en charge l'authentification IAM pour les connexions de réplication.
+ Le jeton d'authentification IAM expire au bout de 15 minutes par défaut. Il se peut que vous deviez actualiser les connexions de réplication de longue durée avant l'expiration du jeton.