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 réplicas en lecture pour Amazon RDS pour PostgreSQL
Vous pouvez mettre à l’échelle les opérations de lecture des instances de base de données Amazon RDS pour PostgreSQL en ajoutant des réplicas en lecture aux instances. Comme pour les autres moteurs de base de données Amazon RDS, RDS pour PostgreSQL utilise les mécanismes de réplication natifs de PostgreSQL pour maintenir les réplicas en lecture à jour avec les modifications apportées à la base de données source. Pour obtenir des informations générales sur les réplicas en lecture et Amazon RDS, consultez [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
Ensuite, vous trouverez des informations propres à l’utilisation des réplicas en lecture avec RDS pour PostgreSQL.
## Limites des réplicas en lecture avec PostgreSQL
Les limites des réplicas en lecture pour PostgreSQL sont les suivantes :
+ Les réplicas en lecture PostgreSQL sont en lecture seule. Bien qu’un réplica en lecture ne soit pas une instance de base de données accessible en écriture, vous pouvez le promouvoir en instance de base de données RDS pour PostgreSQL autonome. Toutefois, le processus n'est pas réversible.
+ Vous ne pouvez pas créer de réplica en lecture à partir d’un autre réplica en lecture si votre instance de base de données RDS pour PostgreSQL exécute une version de PostgreSQL antérieure à 14.1. RDS pour PostgreSQL prend en charge les réplicas en lecture en cascade sur RDS pour PostgreSQL version 14.1 et versions ultérieures uniquement. Pour de plus amples informations, veuillez consulter [Utilisation de réplicas en lecture en cascade avec RDS pour PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ Si vous promouvez un réplica en lecture PostgreSQL, il devient une instance de base de données accessible en écriture. Il arrête de recevoir les fichiers WAL (write-ahead log) d'une instance de base de données source, et n'est plus une instance en lecture seule. Vous pouvez créer des réplicas en lecture à partir de l’instance de base de données promue comme pour n’importe quelle instance de base de données RDS pour PostgreSQL. Pour de plus amples informations, veuillez consulter [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
+ Si vous promouvez un réplica en lecture PostgreSQL depuis une chaîne de réplication (une série de réplicas en lecture en cascade), tous les réplicas en lecture en aval existants continuent de recevoir automatiquement des fichiers WAL de l’instance promue. Pour de plus amples informations, veuillez consulter [Utilisation de réplicas en lecture en cascade avec RDS pour PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ Si aucune transaction utilisateur n'est en cours d'exécution sur l'instance de base de données source, le réplica en lecture PostgreSQL associé signale un retard de réplication pouvant atteindre cinq minutes. Le décalage de réplication est calculé comme `currentTime - lastCommitedTransactionTimestamp`. Cela signifie que lorsqu'aucune transaction n'est traitée, la valeur du décalage de réplication augmente pendant un certain temps jusqu'à ce que le segment WAL (journal d'écriture anticipée) bascule. Par défaut, RDS pour PostgreSQL change le segment WAL toutes les cinq minutes, ce qui entraîne l’enregistrement d’une transaction et une diminution du décalage signalé.
+ Vous ne pouvez pas activer les sauvegardes automatiques pour les réplicas en lecture PostgreSQL pour les versions de RDS pour PostgreSQL antérieures à 14.1. Les sauvegardes automatiques pour les réplicas en lecture sont prises en charge pour RDS pour PostgreSQL 14.1 et versions ultérieures uniquement. Pour RDS pour PostgreSQL 13 et versions antérieures, créez un instantané à partir d’un réplica en lecture si vous souhaitez en obtenir une sauvegarde.
+ Point-in-time la restauration (PITR) n'est pas prise en charge pour les répliques en lecture. Vous pouvez utiliser PITR avec une instance principale (enregistreur) uniquement, pas avec un réplica en lecture. Pour en savoir plus, consultez [Restauration d’une instance de base de données à un instant précis pour Amazon RDS](USER_PIT.md).
+ Les réplicas en lecture pour les versions 12 et inférieures de PostgreSQL redémarrent automatiquement pendant la fenêtre de maintenance de 60 à 90 jours pour appliquer la rotation des mots de passe. Si le réplica perd la connexion à la source avant le redémarrage planifié, il redémarre tout de même pour reprendre la réplication. Pour PostgreSQL versions 13 et ultérieures, les réplicas en lecture peuvent subir de brèves déconnexions et reconnexions pendant le processus de rotation des mots de passe.
# Configuration de réplicas en lecture avec PostgreSQL
RDS for PostgreSQL utilise la réplication en continu native de PostgreSQL pour créer une copie en lecture seule d'une instance de base de données source. Cette instance de base de données de réplica en lecture est un réplica physique créé de façon asynchrone de l'instance de base de données source. Elle est créée par une connexion spéciale qui transmet les données WAL (write-ahead log) entre l'instance de base de données source et le réplica en lecture. Pour plus d'informations, consultez [Streaming Replication](https://www.postgresql.org/docs/14/warm-standby.html#STREAMING-REPLICATION) dans la documentation PostgreSQL.
PostgreSQL diffuse de manière asynchrone les modifications de base de données sur cette connexion sécurisée telles qu'elles sont effectuées sur l'instance de base de données source. Vous pouvez chiffrer les communications entre vos applications clientes et l'instance de base de données source ou tout autre réplica en lecture en définissant le paramètre `ssl` sur `1`. Pour plus d’informations, consultez [Utilisation de SSL avec une instance de base de données PostgreSQL](PostgreSQL.Concepts.General.SSL.md).
PostgreSQL utilise un rôle de *réplication* pour effectuer la réplication en continu. Ce rôle dispose de privilèges, mais vous ne pouvez pas l'utiliser pour modifier des données. PostgreSQL utilise un processus unique pour traiter la réplication.
Vous pouvez créer un réplica en lecture PostgreSQL sans affecter les opérations ou les utilisateurs de l'instance de base de données source. Amazon RDS définit pour vous les paramètres et autorisations nécessaires, sur l'instance de base de données source et le réplica en lecture, sans impacter le service. Un instantané de l'instance de base de données source est pris, et est utilisé pour créer le réplica en lecture. Si vous supprimez le réplica en lecture à un moment donné dans le futur, aucune panne ne se produit.
Vous pouvez créer jusqu'à 15 réplicas en lecture à partir d'une seule instance de base de données source au sein de la même région. Depuis RDS for PostgreSQL 14.1, vous pouvez également créer jusqu'à trois niveaux de réplica en lecture dans une chaîne (cascade) à partir d'une instance de base de données source. Pour de plus amples informations, veuillez consulter [Utilisation de réplicas en lecture en cascade avec RDS pour PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md). Dans tous les cas, les sauvegardes automatisées doivent être configurées sur l'instance de base de données source. Pour cela, vous devez définir la période de conservation des sauvegardes sur votre instance de base de données sur une valeur autre que 0. Pour de plus amples informations, veuillez consulter [Création d’un réplica en lecture](USER_ReadRepl.Create.md).
Vous pouvez créer des réplicas en lecture pour votre instance de base de données RDS for PostgreSQL dans la même Région AWS que votre instance de base de données source. Cette procédure se nomme « réplication *dans la région* ». Vous pouvez également créer des répliques de lecture dans une instance différente Régions AWS de celle de la base de données source. Cette procédure se nomme « réplication *entre régions* ». Pour plus d'informations sur la configuration des réplicas en lecture entre régions, veuillez consulter [Création d'une réplique de lecture dans un autre Région AWS](USER_ReadRepl.XRgn.md). Les différents mécanismes prenant en charge le processus de réplication dans la région et entre régions diffèrent légèrement en fonction de la version de RDS for PostgreSQL, comme expliqué dans [Fonctionnement de la réplication en continu pour différentes versions de RDS pour PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.md).
Pour que la réplication fonctionne de façon efficace, chaque réplica en lecture doit avoir la même quantité de ressources de calcul et de stockage que l'instance de base de données source. Si vous mettez à l'échelle l'instance de base de données source, veillez à le faire également pour les réplicas en lecture.
Amazon RDS remplace tout paramètre incompatible sur un réplica en lecture s'il empêche ce dernier de démarrer. Par exemple, supposons que la valeur du paramètre `max_connections` est supérieure dans l'instance de base de données source à celle du réplica en lecture. Dans ce cas, Amazon RDS met à jour le paramètre dans le réplica en lecture sur la même valeur que celle de l'instance de base de données source.
Les répliques de lecture RDS pour PostgreSQL ont accès à des bases de données externes disponibles via des wrappers de données étrangers FDWs () sur l'instance de base de données source. Par exemple, supposons que votre instance de base de données RDS for PostgreSQL utilise l'encapsuleur `mysql_fdw` pour accéder aux données de RDS for MySQL. Si tel est le cas, vos réplicas en lecture peuvent également accéder à ces données. Les autres supports pris en charge FDWs incluent `oracle_fdw``postgres_fdw`, et`tds_fdw`. Pour de plus amples informations, veuillez consulter [Utilisation des encapsuleurs de données externes pris en charge pour Amazon RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md).
## Utilisation des réplicas en lecture RDS for PostgreSQL avec des configurations multi-AZ
Vous pouvez créer un réplica en lecture à partir de déploiements d'instance de base de données mono-AZ ou Multi-AZ. Vous pouvez utiliser des déploiements multi-AZ pour améliorer la durabilité et la disponibilité des données critiques, avec un réplica de secours. Un *réplica de secours* est un réplica en lecture dédié qui peut assumer la charge de travail en cas de défaillance de la base de données source. Vous ne pouvez pas utiliser votre réplica de secours pour traiter le trafic en lecture. Vous pouvez toutefois créer des réplicas en lecture à partir d'instances de base de données multi-AZ à trafic élevé pour décharger les requêtes en lecture seule. Pour plus d'informations sur les déploiements Multi-AZ, veuillez consulter [Déploiements de l’instance de base de données multi-AZ pour Amazon RDS](Concepts.MultiAZSingleStandby.md).
Si l'instance de base de données source d'un déploiement multi-AZ bascule vers une instance de secours, les réplicas en lecture associés se mettent automatiquement à utiliser l'instance de secours (désormais principale) comme source de réplication. Les réplicas en lecture ont peut-être besoin d'être redémarrés, en fonction de la version de RDS for PostgreSQL, comme suit :
+ **PostgreSQL 13 et versions ultérieures** – Le redémarrage n'est pas obligatoire. Les réplicas en lecture sont automatiquement synchronisés avec la nouvelle instance principale. Toutefois, dans certains cas, votre application cliente risque de mettre en cache les détails du service DNS (Domain Name Service) pour vos réplicas en lecture. Si tel est le cas, définissez la valeur time-to-live (TTL) sur moins de 30 secondes. Cela empêche le réplica en lecture de conserver une adresse IP obsolète (et l'empêche ainsi de se synchroniser avec la nouvelle instance principale). Pour en savoir plus et pour obtenir d'autres bonnes pratiques, consultez [Directives opérationnelles de base Amazon RDS](CHAP_BestPractices.md#CHAP_BestPractices.DiskPerformance).
+ **PostgreSQL 12 et toutes les versions antérieures** – Les réplicas en lecture redémarrent automatiquement après un basculement vers le réplica de secours car ce dernier (désormais principal) a une adresse IP différente et un nom d'instance différent. Le redémarrage synchronise le réplica en lecture avec la nouvelle instance principale.
Pour en savoir plus sur le basculement, consultez [Basculement d’une instance de base de données multi-AZ pour Amazon RDS](Concepts.MultiAZ.Failover.md). Pour plus d'informations sur le fonctionnement des réplicas en lecture dans un déploiement multi-AZ, veuillez consulter [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
Pour prendre en charge le basculement d'un réplica en lecture, vous pouvez créer le réplica en lecture en tant qu'instance de base de données multi-AZ pour que Amazon RDS crée une instance de secours de votre réplica dans une autre zone de disponibilité. La création de votre réplica en lecture en tant qu'instance de base de données multi-AZ est indépendante du fait que la base de données source soit ou non une instance de base de données multi-AZ.
# Décodage logique sur un réplica en lecture
RDS pour PostgreSQL prend en charge la réplication logique à partir d’instances de secours avec PostgreSQL 16.1. Cela vous permet de créer un décodage logique à partir d’une instance de secours en lecture seule qui réduit la charge sur l’instance de base de données principale. Vous pouvez améliorer la disponibilité de vos applications qui doivent synchroniser les données entre plusieurs systèmes. Cette fonctionnalité améliore les performances de votre entrepôt de données et de votre analytique des données.
De plus, les emplacements de réplication d’une instance de secours donnée permettent de continuer à promouvoir cette instance de secours en instance principale. Cela signifie qu’en cas de basculement d’une instance de base de données principale ou de promotion d’une instance de secours en tant que nouvelle instance principale, les emplacements de réplication seront conservés et les anciens abonnés de secours ne seront pas affectés.
**Pour créer un décodage logique sur un réplica en lecture**
1. **Activer la réplication logique** : pour créer un décodage logique sur une instance de secours, vous devez activer la réplication logique sur votre instance de base de données source et son réplica physique. Pour de plus amples informations, veuillez consulter [Configuration de réplicas en lecture avec PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md).
+ **Pour activer la réplication logique pour une instance de base de données RDS pour PostgreSQL nouvellement créée** : créez un nouveau groupe de paramètres personnalisés de base de données et définissez le paramètre statique `rds.logical_replication` sur `1`. Associez ensuite ce groupe de paramètres de base de données à l’instance de base de données source et à sa réplica en lecture physique. Pour de plus amples informations, veuillez consulter [Association d’un groupe de paramètres de base de données à une instance de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Associating.md).
+ **Pour activer la réplication logique pour une instance de base de données RDS pour PostgreSQL existante** : modifiez le groupe de paramètres personnalisés de base de données de l’instance de base de données source et son réplica physique en lecture pour définir le paramètre statique `rds.logical_replication` sur `1`. Pour de plus amples informations, veuillez consulter [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
**Note**
Vous pouvez redémarrer les instances de base de données pour appliquer ces modifications de paramètre.
Vous pouvez utiliser la requête suivante pour vérifier les valeurs pour `wal_level` et `rds.logical_replication` sur l’instance de base de données source et son réplica en lecture physique.
```
Postgres=>SELECT name,setting FROM pg_settings WHERE name IN ('wal_level','rds.logical_replication');
name | setting
-------------------------+---------
rds.logical_replication | on
wal_level | logical
(2 rows)
```
1. **Créez une table dans la base de données source** : connectez-vous à la base de données dans votre instance de base de données source. Pour de plus amples informations, veuillez consulter [Connexion à une instance de base de données exécutant le moteur de base de données PostgreSQL](USER_ConnectToPostgreSQLInstance.md).
Utilisez les requêtes suivantes pour créer une table dans votre base de données source et pour insérer des valeurs :
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
```
Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000));
INSERT 0 10000
```
1. **Créer une publication pour la table source** : utilisez la requête suivante pour créer une publication pour la table sur l’instance de base de données source.
```
Postgres=>CREATE PUBLICATION testpub FOR TABLE LR_test;
CREATE PUBLICATION
```
Utilisez une requête SELECT pour vérifier les détails de la publication créée à la fois sur l’instance de base de données source et sur l’instance physique de réplica en lecture.
```
Postgres=>SELECT * from pg_publication;
oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot
-------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
16429 | testpub | 16413 | f | t | t | t | t | f
(1 row)
```
1. **Créer un abonnement à partir d’une instance de réplica logique** : créez une autre instance de base de données RDS pour PostgreSQL en tant qu’instance de réplica logique. Assurez-vous que le VPC est correctement configuré pour que cette instance de réplica logique puisse accéder à l’instance de réplica physique en lecture. Pour de plus amples informations, veuillez consulter [Amazon VPC et Amazon RDS](USER_VPC.md). Si votre instance de base de données source est inactive, des problèmes de connectivité peuvent survenir et l’instance principale n’envoie pas les données à l’instance de secours.
```
Postgres=>CREATE SUBSCRIPTION testsub CONNECTION 'host=Physical replica host name port=port
dbname=source_db_name user=user password=password' PUBLICATION testpub;
NOTICE: created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
```
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
Utilisez une requête SELECT pour vérifier les détails de l’abonnement sur l’instance de réplica logique.
```
Postgres=>SELECT oid,subname,subenabled,subslotname,subpublications FROM pg_subscription;
oid | subname | subenabled | subslotname | subpublications
-------+---------+------------+-------------+-----------------
16429 | testsub | t | testsub | {testpub}
(1 row)
postgres=> select count(*) from LR_test;
count
-------
10000
(1 row)
```
1. **Inspectez l’état de l’emplacement de réplication logique** : vous ne pouvez voir que l’emplacement de réplication physique sur votre instance de base de données source.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
---------------------------------------------+-----------+---------------------
rds_us_west_2_db_dhqfsmo5wbbjqrn3m6b6ivdhu4 | physical |
(1 row)
```
Toutefois, sur votre instance de réplica en lecture, vous pouvez voir l’emplacement de réplication logique et la valeur `confirmed_flush_lsn` changer à mesure que l’application consomme activement des modifications logiques.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/500002F0
(1 row)
```
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/5413F5C0
(1 row)
```
# Utilisation de réplicas en lecture en cascade avec RDS pour PostgreSQL
À partir de la version 14.1, RDS pour PostgreSQL prend en charge les réplicas en lecture en cascade. Les *réplicas en lecture en cascade* vous permettent de mettre à l’échelle les lectures sans surcharger votre instance de base de données RDS pour PostgreSQL source. Les mises à jour du journal WAL ne sont pas envoyées par l'instance de base de données source à chaque réplica en lecture. Au lieu de cela, chaque réplica en lecture d'une série en cascade envoie les mises à jour du journal WAL au réplica en lecture suivant de la série. Cela réduit la charge pesant sur l'instance de base de données source.
Avec les réplicas en lecture en cascade, votre instance de base de données RDS pour PostgreSQL envoie des données WAL au premier réplica en lecture de la chaîne. Ce réplica en lecture envoie ensuite des données WAL au deuxième réplica de la chaîne, etc. Au final, tous les réplicas en lecture de la chaîne ont reçu les modifications de l’instance de base de données RDS pour PostgreSQL, sans surcharger uniquement l’instance de base de données source.
Vous pouvez créer une série comportant jusqu’à trois réplicas en lecture dans une chaîne à partir d’une instance de base de données RDS pour PostgreSQL source. Par exemple, supposons que vous disposez d’une instance de base de données RDS pour PostgreSQL 14.1, `rpg-db-main`. Vous pouvez effectuer les opérations suivantes :
+ À partir de `rpg-db-main`, créez le premier réplica en lecture de la chaîne, `read-replica-1`.
+ Ensuite, à partir de `read-replica-1`, créez le réplica en lecture suivant dans la chaîne, `read-replica-2`.
+ Enfin, à partir de `read-replica-2`, créez le troisième réplica en lecture de la chaîne, `read-replica-3`.
Vous ne pouvez pas créer un autre réplica en lecture au-delà de ce troisième réplica en lecture en cascade dans la série pour `rpg-db-main`. Une série complète d’instances allant d’une instance de base de données source RDS pour PostgreSQL à la fin d’une série de réplicas en lecture en cascade peut comporter jusqu’à quatre instances de bases de données.
Pour que les réplicas en lecture en cascade fonctionnent, activez les sauvegardes automatiques sur RDS pour PostgreSQL. Commencez par créer le réplica en lecture, puis activez les sauvegardes automatiques sur l’instance de base de données RDS pour PostgreSQL. Le processus est le même que pour les autres moteurs de base de données Amazon RDS. Pour de plus amples informations, veuillez consulter [Création d’un réplica en lecture](USER_ReadRepl.Create.md).
Comme pour tout réplica en lecture, vous pouvez promouvoir un réplica en lecture faisant partie d'une cascade. La promotion d'un réplica en lecture depuis une chaîne de réplicas en lecture retire ce réplica de la chaîne. Par exemple, supposons que vous souhaitez déplacer une partie de la charge de travail de votre instance de base de données `rpg-db-main` vers une nouvelle instance destinée uniquement au service comptable. En prenant pour hypothèse la chaîne de trois réplicas en lecture de l'exemple, vous décidez de promouvoir `read-replica-2`. La chaîne est affectée comme suit :
+ La promotion de `read-replica-2` le retire de la chaîne de réplication.
+ Il s'agit désormais d'une read/write instance de base de données complète.
+ La réplication continue sur `read-replica-3`, tout comme avant la promotion.
+ Votre `rpg-db-main` continue la réplication sur `read-replica-1`.
Pour plus d'informations sur la promotion des réplicas en lecture, consultez [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
**Note**
RDS pour PostgreSQL ne prend pas en charge les mises à niveau des versions majeures pour les réplicas en cascade. Avant de procéder à une mise à niveau de version majeure, vous devez supprimer les réplicas en cascade. Vous pouvez les recréer après avoir terminé la mise à niveau sur votre instance de base de données source et sur les réplicas de premier niveau.
Pour les réplicas en lecture en cascade, RDS pour PostgreSQL prend en charge 15 réplicas en lecture pour chaque instance de base de données source au premier niveau de réplication, et 5 réplicas en lecture pour chaque instance de base de données source aux deuxième et troisième niveaux de réplication.
# Création de réplicas en lecture en cascade entre régions avec RDS pour PostgreSQL
RDS pour PostgreSQL prend en charge les réplicas en lecture en cascade entre régions. Vous pouvez créer un réplica entre régions à partir de l’instance de base de données source, puis créer des réplicas dans la même région à partir de celui-ci. Vous pouvez créer un réplica dans la même région à partir de l’instance de base de données source, puis créer des réplicas entre régions à partir de celui-ci.
**Création d’un réplica entre régions, puis création de réplicas dans la même région**
Vous pouvez utiliser une instance de base de données RDS pour PostgreSQL en version 14.1 ou supérieure, `rpg-db-main`, pour effectuer les opérations suivantes :
1. Commencez par `rpg-db-main` (USA-EST-1), créez le premier réplica en lecture entre régions de la chaîne, `read-replica-1` (USA-OUEST-2).
1. À l’aide du premier réplica entre régions `read-replica-1` (USA-OUEST-2), créez le deuxième réplica en lecture de la chaîne, `read-replica-2` (USA-OUEST-2).
1. À l’aide de `read-replica-2`, créez le troisième réplica en lecture de la chaîne, `read-replica-3` (USA-OUEST-2).
**Création d’un réplica dans la même région, puis création de réplicas entre régions**
Vous pouvez utiliser une instance de base de données RDS pour PostgreSQL en version 14.1 ou supérieure, `rpg-db-main`, pour effectuer les opérations suivantes :
1. À partir de `rpg-db-main` (USA-EST-1), créez le premier réplica en lecture de la chaîne, `read-replica-1` (USA-EST-1).
1. À l’aide de `read-replica-1` (USA-EST-1), créez le premier réplica en lecture entre régions de la chaîne, `read-replica-2` (USA-OUEST-2).
1. À l’aide de `read-replica-2` (USA-OUEST-2), créez le troisième réplica en lecture de la chaîne, `read-replica-3` (USA-OUEST-2).
**Limitations liées à la création de réplicas en lecture entre régions**
+ Une chaîne en cascade entre régions de réplicas de bases de données peut couvrir au maximum deux régions, avec un maximum de quatre niveaux. Les quatre niveaux incluent la source de base de données et trois réplicas en lecture.
**Avantages de l’utilisation de réplicas en lecture en cascade**
+ Capacité de mise à l’échelle de lecture améliorée : en répartissant les requêtes de lecture entre plusieurs réplicas, la réplication en cascade permet d’équilibrer la charge. Cela améliore les performances, en particulier dans les applications nécessitant beaucoup de lecture, en réduisant la charge de travail de la base de données d’enregistreur.
+ Répartition géographique : les réplicas en cascade peuvent être situés dans différents emplacements géographiques. Cela réduit le temps de latence pour les utilisateurs éloignés de la base de données principale et fournit un réplica en lecture local, améliorant ainsi les performances et l’expérience utilisateur.
+ Haute disponibilité et reprise après sinistre : en cas de panne d’un serveur principal, les réplicas peuvent être promus au rang d’instances principales, ce qui garantit la continuité. La réplication en cascade améliore encore cela en proposant plusieurs niveaux d’options de basculement, améliorant ainsi la résilience globale du système.
+ Flexibilité et croissance modulaire : à mesure que le système se développe, de nouveaux réplicas peuvent être ajoutés à différents niveaux sans reconfiguration majeure de la base de données principale. Cette approche modulaire permet une croissance évolutive et gérable de la configuration de réplication.
**Bonnes pratiques en matière d’utilisation de réplicas en lecture entre régions**
+ Avant de promouvoir un réplica, créez des réplicas supplémentaires. Cela permet de gagner du temps et de gérer efficacement la charge de travail.
# Fonctionnement de la réplication en continu pour différentes versions de RDS pour PostgreSQL
Comme indiqué dans [Configuration de réplicas en lecture avec PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md), RDS pour PostgreSQL utilise le protocole de réplication en continu natif de PostgreSQL pour envoyer des données WAL à partir de l’instance de base de données source. Il envoie les données WAL source aux réplicas en lecture pour les réplicas en lecture dans la région et entre régions. Avec la version 9.4, PostgreSQL a introduit des emplacements de réplication physiques comme mécanisme de prise en charge du processus de réplication.
Un *emplacement de réplication physique* empêche une instance de base de données source de supprimer les données WAL avant qu'elles ne soient utilisées par tous les réplicas en lecture. Chaque réplica en lecture possède son propre emplacement physique sur l'instance de base de données source. L'emplacement permet de suivre le WAL le plus ancien (par numéro de séquence logique, LSN) qui pourrait être requis par le réplica. Une fois que tous les emplacements et les connexions à la base de données ont dépassé un WAL (LSN) donné, le LSN devient candidat à la suppression au point de contrôle suivant.
Amazon RDS utilise Amazon S3 pour archiver les données WAL. Pour les réplicas en lecture dans la région, vous pouvez utiliser ces données archivées pour restaurer le réplica en lecture si nécessaire. Par exemple, vous pouvez le faire si la connexion entre la base de données source et le réplica en lecture est interrompue pour quelque raison que ce soit.
Le tableau suivant résume les différences entre les versions de PostgreSQL et les mécanismes de prise en charge pour la réplication dans la région et entre régions utilisée par RDS pour PostgreSQL.
| Version | Dans la région | Entre régions |
| --- | --- | --- |
| PostgreSQL 14.1 et versions ultérieures | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
| PostgreSQL 13 et versions inférieures | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
Pour de plus amples informations, veuillez consulter [Surveillance et réglage du processus de réplication](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md).
## Analyse des paramètres qui contrôlent la réplication PostgreSQL
Les paramètres suivants affectent le processus de réplication et déterminent dans quelle mesure les réplicas en lecture restent à jour avec l'instance de base de données source :
**max\$1wal\$1senders**
Le paramètre `max_wal_senders` spécifie le nombre maximal de connexions que l'instance de base de données source peut prendre en charge en même temps via le protocole de réplication en continu.
La valeur par défaut varie selon les versions de RDS pour PostgreSQL :
+ Pour les versions 13, 14 et 15, la valeur par défaut est 20.
+ Pour les versions 16 et supérieures, la valeur par défaut est 35.
Ce paramètre doit être défini sur une valeur légèrement supérieure au nombre réel de réplicas en lecture. Si la valeur est trop faible pour le nombre de réplicas en lecture, la réplication s'arrête.
Pour plus d'informations, consultez [max\$1wal\$1senders](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-WAL-SENDERS) dans la documentation PostgreSQL.
`max_wal_senders` est un paramètre statique qui nécessite un redémarrage de l’instance de base de données pour que les modifications prennent effet.
**wal\$1keep\$1segments**
Le paramètre `wal_keep_segments` spécifie le nombre de fichiers WAL (write-ahead log) conservés par l'instance de base de données source dans le répertoire `pg_wal`. La valeur par défaut est 32.
Si la valeur de `wal_keep_segments` n'est pas suffisante pour votre déploiement, un réplica en lecture peut prendre un retard tel que la réplication en continu s'arrête. Dans ce cas, Amazon RDS génère une erreur de réplication et commence la récupération des données sur le réplica en lecture. Pour ce faire, il relit les données WAL archivées de l'instance de base de données source à partir d'Amazon S3. Ce processus de récupération se poursuit jusqu'à ce que le réplica en lecture ait rattrapé suffisamment de retard pour continuer la réplication en continu. Pour voir ce processus en action tel qu'il est capturé par le journal PostgreSQL, consultez [Exemple : Récupération d'un réplica en lecture à la suite d'interruptions de réplicationExemple : Récupération d'un réplica en lecture à la suite d'interruptions de réplication](#USER_PostgreSQL.Replication.example-how-it-works).
Dans PostgreSQL version 13, le paramètre `wal_keep_segments` est nommé `wal_keep_size`. Il a le même objectif que `wal_keep_segments`, mais sa valeur par défaut est exprimée en mégaoctets (Mo) (2 048 Mo) plutôt qu'en nombre de fichiers. Pour plus d’informations, consultez [wal\$1keep\$1segments](https://www.postgresql.org/docs/12/runtime-config-replication.html#GUC-WAL-KEEP-SEGMENTS) et [wal\$1keep\$1size](https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-WAL-KEEP-SIZE) dans la documentation PostgreSQL.
**max\$1slot\$1wal\$1keep\$1size**
Le paramètre `max_slot_wal_keep_size` contrôle la quantité de données WAL conservée par l’instance de base de données RDS pour PostgreSQL dans le répertoire `pg_wal` pour remplir les emplacements. Ce paramètre est utilisé pour les configurations utilisant des emplacements de réplication. La valeur par défaut de ce paramètre est `-1`, ce qui signifie que la quantité de données WAL conservées sur l'instance de base de données source n'est pas limitée. Pour en savoir plus sur la surveillance de vos emplacements de réplication, consultez [Surveillance des emplacements de réplication pour votre instance de base de données RDS pour PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md#USER_PostgreSQL.Replication.ReadReplicas.Monitor-monitor-replication-slots).
Pour plus d’informations sur ce paramètre, consultez [max\$1slot\$1wal\$1keep\$1size](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-SLOT-WAL-KEEP-SIZE) dans la documentation PostgreSQL.
Chaque fois que le flux qui fournit les données WAL à un réplica en lecture est interrompu, PostgreSQL bascule en mode de récupération. Il restaure le réplica en lecture à l’aide des données WAL archivées d’Amazon S3 ou avec les données WAL associées à l’emplacement de réplication. Une fois ce processus terminé, PostgreSQL rétablit la réplication en continu.
### Exemple : Récupération d'un réplica en lecture à la suite d'interruptions de réplication
L'exemple suivant fournit les détails du journal qui illustrent le processus de récupération d'un réplica en lecture. L'exemple provient d'une instance de base de données RDS pour PostgreSQL exécutant PostgreSQL version 12.9 dans la Région AWS même base de données que la base de données source, de sorte que les emplacements de réplication ne sont pas utilisés. Le processus de récupération est le même pour les autres instances de base de données RDS pour PostgreSQL exécutant des versions de PostgreSQL antérieures à la version 14.1 avec des réplicas en lecture dans la région.
Lorsque le réplica en lecture a perdu le contact avec l'instance de base de données source, Amazon RDS enregistre le problème dans le journal sous la forme d'un message `FATAL: could not receive data from WAL stream`, ainsi que `ERROR: requested WAL segment ... has already been removed`. Comme indiqué sur la ligne en gras, Amazon RDS récupère le réplica en relisant un fichier WAL archivé.
```
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: switched WAL source from archive to stream after failure
2014-11-07 19:01:10 UTC::@:[11575]:LOG: started streaming WAL from primary at 1A/D3000000 on timeline 1
2014-11-07 19:01:10 UTC::@:[11575]:FATAL: could not receive data from WAL stream:
ERROR: requested WAL segment 000000010000001A000000D3 has already been removed
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: could not restore file "00000002.history" from archive: return code 0
2014-11-07 19:01:15 UTC::@:[23180]:DEBUG: switched WAL source from stream to archive after failure recovering 000000010000001A000000D3
2014-11-07 19:01:16 UTC::@:[23180]:LOG: restored log file "000000010000001A000000D3" from archive
```
Lorsqu'Amazon RDS relit un nombre suffisant de données WAL archivées sur le réplica pour qu'il rattrape son retard, le streaming vers le réplica en lecture reprend. Lorsque le streaming reprend, Amazon RDS écrit une entrée dans le fichier journal, semblable à ce qui suit.
```
2014-11-07 19:41:36 UTC::@:[24714]:LOG:started streaming WAL from primary at 1B/B6000000 on timeline 1
```
## Définition des paramètres qui contrôlent la mémoire partagée
Les paramètres que vous définissez déterminent la taille de la mémoire partagée pour le suivi des transactions IDs, des verrous et des transactions préparées. **La structure de mémoire partagée d'une instance de secours doit être égale ou supérieure à celle d'une instance principale.** Cela garantit que la première ne viendra pas à manquer de mémoire partagée lors de la récupération. Si les valeurs des paramètres sur le réplica sont inférieures aux valeurs des paramètres sur l'instance principale, Amazon RDS ajuste automatiquement les paramètres de réplica et redémarre le moteur.
Les paramètres concernés sont les suivants :
+ max\$1connections
+ max\$1worker\$1processes
+ max\$1wal\$1senders
+ max\$1prepared\$1transactions
+ max\$1locks\$1per\$1transaction
Pour éviter le redémarrage des réplicas par RDS en raison d'un manque de mémoire, nous recommandons d'appliquer les modifications de paramètres à chaque réplica sous la forme d'un redémarrage progressif. Vous devez appliquer les règles suivantes lorsque vous définissez les paramètres :
+ **Augmentation des valeurs des paramètres :**
+ Vous devez toujours d'abord augmenter les valeurs des paramètres de tous les réplicas lus, puis effectuer un redémarrage progressif de tous les réplicas. Appliquez ensuite les modifications de paramètres sur l'instance principale et redémarrez.
+ **Diminution des valeurs des paramètres :**
+ Vous devez d'abord diminuer les valeurs des paramètres de l'instance principale, puis effectuer un redémarrage. Appliquez ensuite les modifications des paramètres à tous les réplicas de lecture associés et effectuez un redémarrage progressif.
# Surveillance et réglage du processus de réplication
Nous vous recommandons fortement de surveiller régulièrement votre instance de base de données RDS pour PostgreSQL et vos réplicas en lecture. Vous devez vous assurer que vos réplicas en lecture suivent le rythme des modifications apportées à l'instance de base de données source. Amazon RDS récupère de manière transparente vos réplicas en lecture lorsque le processus de réplication est interrompu. Cependant, il est préférable d'éviter toute récupération. La récupération à l'aide d'emplacements de réplication est plus rapide que l'utilisation de l'archive Amazon S3, mais tout processus de récupération peut affecter les performances de lecture.
Pour déterminer dans quelle mesure vos réplicas en lecture suivent le rythme de l'instance de base de données source, vous pouvez effectuer les opérations suivantes :
+ **Vérifiez la valeur de `ReplicaLag` entre l'instance de base de données source et les réplicas.** Le *retard du réplica* correspond au retard en secondes qu'accuse un réplica en lecture par rapport à son instance de base de données source. Cette métrique renvoie le résultat de la requête suivante.
```
SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";
```
Le délai de réplication indique dans quelle mesure un réplica en lecture suit le rythme de l'instance de base de données source. Il s'agit de la latence entre l'instance de base de données source et une instance de lecture spécifique. Une valeur de délai de réplication élevée peut indiquer une non-correspondance entre les classes d'instance de base de données et/ou les types de stockages utilisés par l'instance de base de données source et ses réplicas en lecture. La classe d'instance de base de données et les types de stockages pour l'instance de base de données source et tous les réplicas en lecture doivent être identiques.
Le délai de réplication peut également être issu de problèmes de connexion intermittents. Vous pouvez surveiller le délai de réplication dans Amazon CloudWatch en consultant la `ReplicaLag` métrique Amazon RDS. Pour en savoir plus sur `ReplicaLag` et d’autres métriques pour Amazon RDS, consultez [CloudWatch Métriques Amazon pour Amazon RDS](rds-metrics.md).
+ **Consultez le journal PostgreSQL pour obtenir des informations que vous pouvez utiliser pour ajuster vos paramètres.** À chaque point de contrôle, le journal PostgreSQL capture le nombre de fichiers journaux de transactions recyclés, comme illustré dans l'exemple suivant.
```
2014-11-07 19:59:35 UTC::@:[26820]:LOG: checkpoint complete: wrote 376 buffers (0.2%);
0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s;
sync files=10, longest=0.013 s, average=0.001 s
```
Vous pouvez utiliser ces informations pour déterminer le nombre de fichiers de transactions qui sont recyclés au cours d'une période donnée. Vous pouvez ensuite modifier la valeur de `wal_keep_segments` si nécessaire. Par exemple, supposons que le journal PostgreSQL à `checkpoint complete` montre `35 recycled` pour une intervalle de 5 minutes. Dans ce cas, la valeur par défaut de `wal_keep_segments` (32) n'est pas suffisante pour suivre le rythme de l'activité de streaming. Nous vous recommandons ainsi d'augmenter la valeur de ce paramètre.
+ **Utilisez Amazon CloudWatch pour surveiller les indicateurs permettant de prévoir les problèmes de réplication.** Plutôt que d'analyser directement le journal PostgreSQL, vous pouvez utiliser CloudWatch Amazon pour vérifier les métriques collectées. Par exemple, vous pouvez consulter la valeur de la métrique `TransactionLogsGeneration` pour obtenir la quantité de données WAL générées par l'instance de base de données source. Dans certains cas, la charge de travail de votre instance de base de données risque de générer une grande quantité de données WAL. Si tel est le cas, vous devrez peut-être modifier la classe de votre instance de base de données source et de vos réplicas en lecture. L'utilisation d'une classe d'instance avec des performances réseau élevées (10 Gbit/s) peut réduire le délai de réplication.
## Surveillance des emplacements de réplication pour votre instance de base de données RDS pour PostgreSQL
Toutes les versions de RDS pour PostgreSQL utilisent des emplacements de réplication pour les réplicas en lecture entre régions. RDS pour PostgreSQL 14.1 et versions ultérieures utilisent des emplacements de réplication pour les réplicas en lecture dans la région. Les réplicas en lecture dans la région utilisent également Amazon S3 pour archiver les données WAL. En d'autres termes, si votre instance de base de données et vos réplicas en lecture exécutent PostgreSQL 14.1 ou versions ultérieures, les emplacements de réplication et les archives Amazon S3 sont disponibles pour récupérer le réplica en lecture. La récupération d'un réplica en lecture à l'aide de son emplacement de réplication est plus rapide que la récupération à partir d'une archive Amazon S3. Nous vous recommandons donc de surveiller les emplacements de réplication et les métriques associées.
Vous pouvez afficher les emplacements de réplication sur vos instances de base de données RDS pour PostgreSQL en interrogeant la vue `pg_replication_slots`, comme suit.
```
postgres=> SELECT * FROM pg_replication_slots;
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
---------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
rds_us_west_1_db_555555555 | | physical | | | f | t | 13194 | | | 23/D8000060 | | reserved | | f
(1 row)
```
La valeur `reserved` de `wal_status` signifie que la quantité de données WAL détenue par l'emplacement se situe dans les limites du paramètre `max_wal_size`. En d'autres termes, la taille de l'emplacement de réplication est correcte. Les autres valeurs de statut possibles sont les suivantes :
+ `extended` – L'emplacement dépasse la valeur de `max_wal_size`, mais les données WAL sont conservées.
+ `unreserved` – L'emplacement ne contient plus toutes les données WAL requises. Une partie sera supprimée au prochain point de contrôle.
+ `lost` – Certaines données WAL requises ont été supprimées. L'emplacement n'est plus utilisable.
Les états `lost` et `unreserved` de `wal_status` ne sont visibles que lorsque `max_slot_wal_keep_size` n’est pas négatif.
La vue `pg_replication_slots` affiche l'état actuel de vos emplacements de réplication. Pour évaluer les performances de vos emplacements de réplication, vous pouvez utiliser Amazon CloudWatch et surveiller les indicateurs suivants :
+ **`OldestReplicationSlotLag`** : indique la quantité de données du journal d’écriture anticipée (WAL) de la source qui n’a pas été consommée par le réplica le plus en retard.
+ **`TransactionLogsDiskUsage`** : indique la quantité de stockage utilisée pour les données WAL. Lorsqu'un réplica en lecture est significativement en retard, la valeur de cette métrique peut augmenter considérablement.
Pour en savoir plus sur l'utilisation d'Amazon CloudWatch et de ses métriques pour RDS pour PostgreSQL, consultez. [Surveillance des métriques Amazon RDS () avec Amazon CloudWatch](monitoring-cloudwatch.md) Pour plus d’informations sur la surveillance de la réplication en continu sur vos instances de base de données RDS pour PostgreSQL, consultez [Best practices for Amazon RDS PostgreSQL replication](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/) sur *AWS Database Blog*.
# Configuration de la réplication différée avec RDS pour PostgreSQL
## Présentation et avantages
La fonctionnalité de réplication différée de RDS pour PostgreSQL vous permet de retarder intentionnellement la réplication des modifications de données de votre base de données principale vers un ou plusieurs serveurs de secours (réplica en lecture). Cela fournit une protection précieuse contre la corruption des données, les pertes de données accidentelles ou les transactions erronées, qui pourraient autrement être immédiatement propagées à tous les réplicas.
La réplication différée est prise en charge sur les versions suivantes de RDS pour PostgreSQL :
+ 14.19 et versions 14 ultérieures
+ 15.14 et versions 15 ultérieures
+ 16.10 et versions 16 ultérieures
+ 17.6 et versions supérieures 17
En introduisant un décalage dans le processus de réplication, vous disposez d’une opportunité pour détecter les incidents liés aux données et les traiter avant qu’ils n’affectent l’ensemble de votre cluster de bases de données. Les avantages de la réplication différée sont les suivants :
+ Elle vous permet de récupérer après des suppressions accidentelles, des mises à jour ou d’autres erreurs logiques.
+ Elle fournit une mémoire tampon contre la propagation de données corrompues dans votre cluster de bases de données.
+ Elle offre une option de point de restauration supplémentaire pour compléter vos stratégies de sauvegarde traditionnelles.
+ Elle vous permet de configurer le délai en fonction des besoins spécifiques de votre organisation et de sa tolérance au risque.
## Activation et configuration de la réplication différée
Pour activer la réplication différée sur un réplica en lecture RDS pour PostgreSQL, suivez ces étapes :
**Note**
Pour les réplicas en lecture en cascade, utilisez le même paramètre `recovery_min_apply_delay` et les mêmes étapes que ceux décrits ci-dessous.
**Pour activer la réplication différée**
1. Créez un nouveau groupe de paramètres personnalisés ou modifiez-en un existant. Pour de plus amples informations, veuillez consulter [Groupes de paramètres de base de données pour les instances de base de données Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md).
1. Configurez le paramètre `recovery_min_apply_delay` dans le groupe de paramètres :
+ Définissez la valeur sur le délai souhaité en millisecondes. Par exemple, 3600000 pour un délai d’une heure.
+ Plage autorisée : 0 à 86400000 ms (0 à 24 heures)
+ Par défaut : 0
1. Appliquez le groupe de paramètres à l’instance de réplica en lecture que vous souhaitez configurer pour une réplication différée.
1. Pour que les modifications deviennent effectives, redémarrez l’instance de réplica en lecture.
**Note**
Le paramètre `recovery_min_apply_delay` est dynamique. Si vous modifiez un groupe de paramètres existant déjà attaché à l’instance, les modifications prennent effet immédiatement sans nécessiter de redémarrage. Toutefois, lorsque vous appliquez un nouveau groupe de paramètres à l’instance, vous devez redémarrer l’instance pour que les modifications prennent effet.
## Gestion de la récupération par réplication différée
La réplication différée est particulièrement utile dans les scénarios où les méthodes point-in-time de restauration traditionnelles peuvent être insuffisantes ou prendre trop de temps.
Pendant la période de réplication différée, vous pouvez utiliser les fonctions PostgreSQL suivantes pour gérer le processus de récupération :
+ `pg_wal_replay_pause()` : demandez la suspension du processus de récupération du réplica différé.
+ `pg_wal_replay_resume()` : redémarrez le processus de récupération s’il a été suspendu.
+ `pg_is_wal_replay_paused()` : vérifiez si le processus de récupération est actuellement suspendu.
+ `pg_get_wal_replay_pause_state()` : obtenez l’état actuel du processus de récupération (non suspendu, pause demandée ou suspendu).
Les utilisateurs dotés du rôle `rds_superuser` disposent des privilèges EXECUTE sur `pg_wal_replay_pause()` et `pg_wal_replay_resume()`. Si d’autres utilisateurs de base de données ont besoin d’accéder à ces fonctions, vous devez leur accorder le rôle `rds_superuser`. Pour plus d'informations sur le rôle `rds_superuser`, consultez [Comprendre le rôle rds\$1superuser](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md).
L’accès à d’autres fonctions, telles que `pg_is_wal_replay_paused()` et `pg_get_wal_replay_pause_state()`, ne requiert pas le rôle `rds_superuser`.
Vous pouvez utiliser les paramètres de cible de récupération suivants pour contrôler avec précision le moment auquel la réplique différée est récupérée. Ces paramètres sont statiques et nécessitent un redémarrage de la base de données pour que les modifications soient appliquées :
+ recovery\$1target
+ recovery\$1target\$1lsn
+ recovery\$1target\$1name
+ recovery\$1target\$1time
+ recovery\$1target\$1xid
+ recovery\$1target\$1inclusive
**Important**
Vous pouvez spécifier uniquement un paramètre de cible de récupération à la fois. La configuration de plusieurs paramètres de cible de récupération dans le fichier de configuration entraîne une erreur.
## Considérations relatives à planification
Procédez comme suit lorsque vous planifiez la réplication différée avec RDS pour PostgreSQL :
+ Lors de la rotation automatique des informations d’identification `rdsrepladmin` (qui a lieu tous les 90 jours), les replicas en lecture différée peuvent entrer temporairement dans un état `REPLICATION_ERROR`. Si le réplica différé possède suffisamment de journaux WAL pour maintenir le délai configuré, il peut interrompre le processus du récepteur WAL, provoquant une accumulation de WAL sur la source. Vous devez surveiller l’état de réplication sur le réplica et la consommation de stockage sur la source pour éviter d’utiliser tout l’espace de stockage.
+ Lorsque les réplicas à lecture différée rencontrent des événements système (tels que le redémarrage), ils entrent dans un état `REPLICATION_ERROR` dans lequel le processus du récepteur WAL reste inactif jusqu’à l’expiration du délai configuré. Ce comportement peut entraîner une accumulation de WAL sur l’instance source, ce qui peut entraîner un épuisement du stockage. Envisagez d’appliquer les mesures préventives suivantes :
+ Configurez des CloudWatch alarmes pour surveiller l'utilisation du stockage sur les instances sources.
+ Activez l’autoscaling du stockage pour faire face à la croissance inattendue de WAL.
+ Définissez le paramètre `max_slot_wal_keep_size` sur l’instance source pour limiter la rétention WAL par slot de réplication.
+ Surveillez régulièrement le délai de réplication et l’état du slot.
+ L’allongement des délais augmente le nombre de journaux WAL sur les réplicas, ce qui consomme plus d’espace de stockage. Surveillez l'espace de stockage à l'aide d' CloudWatch alarmes, activez l'auto-scaling ou récupérez les répliques en cas de besoin.
+ Lors de la promotion d’un réplica à lecture différée, le paramètre `recovery_min_apply_delay` n’est pas respecté et tous les enregistrements WAL en attente sont immédiatement appliqués.
+ Le paramètre `recovery_min_apply_delay` est indépendant de chaque niveau d’une configuration de réplication en cascade. La définition d’un délai pour un réplica n’augmente pas le délai des réplicas en cascade.
Pour plus d’informations, consultez la documentation [Réplicas en lecture RDS pour PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) et la documentation [Reprise après sinistre RDS pour PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Disaster-Recovery.html).
## Présentation des limitations
La fonctionnalité de réplication différée pour Amazon RDS pour PostgreSQL présente les limitations suivantes :
+ Les déploiements bleu/vert présentent les limitations suivantes lors de la configuration de la réplication différée :
+ **Instance source verte** : `recovery_min_apply_delay parameter` n’est pas pris en compte, même s’il est configuré dans le groupe de paramètres. Aucun paramètre de délai sur l’instance source verte ne prend effet.
+ **Instance de réplica verte** : `recovery_min_apply_delay parameter` est entièrement pris en charge et appliqué au fichier de configuration PostgreSQL. Les paramètres de délai fonctionnent comme prévu pendant le flux de travail de bascule.
+ Blue/Green Déploiements RDS pour les mises à niveau de versions majeures
+ Lors des mises à niveau des versions majeures, tous les réplicas en lecture différée seront automatiquement interrompus pour permettre à l’instance source de poursuivre le processus de mise à niveau, afin de garantir une durée d’indisponibilité minimale. Une fois que l’instance source a terminé la mise à niveau, vous devez recréer manuellement les réplicas différés.
+ La réplication différée n’est pas compatible avec les fonctionnalités suivantes.
+ Réplication logique RDS pour PostgreSQL
+ Clusters multi-AZ RDS pour PostgreSQL (y compris la réplication entrante et sortante)
+ Aurora PostgreSQL
# Résolution de problèmes liés aux réplicas en lecture RDS pour PostgreSQL
Vous trouverez ci-dessous des idées pour résoudre problèmes courants liés aux réplicas en lecture RDS pour PostgreSQL.
**Mettre fin à la requête à l’origine du retard du réplica en lecture**
Les transactions à l’état actif ou inactif qui s’exécutent pendant une longue période dans la base de données peuvent interférer avec le processus de réplication WAL, augmentant ainsi le retard de réplication. Veillez donc à surveiller le temps d’exécution de ces transactions à l’aide de la vue `pg_stat_activity` PostgreSQL.
Exécutez une requête similaire à la suivante sur l’instance principale pour trouver l’ID de processus (PID) de la requête exécutée depuis longtemps :
```
SELECT datname, pid,usename, client_addr, backend_start,
xact_start, current_timestamp - xact_start AS xact_runtime, state,
backend_xmin FROM pg_stat_activity WHERE state='active';
```
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
Après avoir identifié le PID de la requête, vous pouvez choisir de mettre fin à la requête.
Exécutez une requête similaire à la suivante sur l’instance principale pour mettre fin à la requête exécutée depuis longtemps :
```
SELECT pg_terminate_backend(PID);
```