Utilisation de réplicas en lecture pour Amazon RDS for PostgreSQL - Amazon Relational Database Service
Décodage logique sur une réplique lueLimites des réplicas en lecture avec PostgreSQLConfiguration de réplicas en lecture avec PostgreSQLFonctionnement de la réplication pour différentes versions de RDS for PostgreSQLSurveillance et réglage du processus de réplicationRésolution des problèmes liés à la réplication en lecture de RDS pour PostgreSQL

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 for PostgreSQL

Vous pouvez dimensionner les lectures pour vos instances de base de données Amazon RDS for PostgreSQL en ajoutant des répliques de lecture aux instances. Comme 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épliques en lecture à jour en fonction des 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.

Ensuite, vous trouverez des informations propres à l'utilisation des réplicas en lecture avec RDS for PostgreSQL.

Décodage logique sur une réplique lue

RDS pour PostgreSQL prend en charge la réplication logique en mode veille avec PostgreSQL 16.1. Cela vous permet de créer un décodage logique à partir d'un mode veille 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 vos analyses de données.

En outre, les emplacements de réplication d'un serveur de secours donné permettent de continuer à transformer ce serveur de secours en serveur principal. 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 une réplique lue

  1. Activer la réplication logique : pour créer un décodage logique en mode veille, vous devez activer la réplication logique sur votre instance de base de données source et sa réplique physique. Pour plus d’informations, consultez Configuration de réplicas en lecture avec PostgreSQL.

    • 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 sur. rds.logical_replication 1 Associez ensuite ce groupe de paramètres de base de données à l'instance de base de données source et à sa réplique de lecture physique. Pour plus d’informations, consultez Association d'un groupe de paramètres de base de données à une instance de base de données.

    • 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 sa réplique de lecture physique pour définir le paramètre statique sur. rds.logical_replication 1 Pour plus d’informations, consultez Modification de paramètres dans un groupe de paramètres de bases de données.

    Note

    Vous devez redémarrer l'instance de base de données pour appliquer ces modifications de paramètres.

    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 sa réplique de 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)

  2. 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 plus d’informations, consultez Connexion à une instance de base de données exécutant le moteur de base de données PostgreSQL.

    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

  3. 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éplication 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)

  4. Créer un abonnement à partir d'une instance de réplique logique : créez une autre instance de base de données RDS pour PostgreSQL en tant qu'instance de réplique logique. Assurez-vous que le VPC est correctement configuré pour que cette instance de réplique logique puisse accéder à l'instance de réplique physique en lecture. Pour plus d’informations, consultez Amazon VPC et Amazon RDS. Si votre instance de base de données source est inactive, des problèmes de connectivité peuvent survenir et le serveur principal n'envoie pas les données en veille.

    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éplique 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)

  5. Inspectez l'état du slot de réplication logique : vous ne pouvez voir que le slot 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éplication en lecture, vous pouvez voir le slot de réplication logique et la confirmed_flush_lsn valeur changer au fur et à 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)

Limites des réplicas en lecture avec PostgreSQL

Les limites des réplicas en lecture pour PostgreSQL sont les suivantes :

Note

Une réplique en lecture pour une instance de base de données multi-AZ et mono-AZ RDS pour PostgreSQL exécutant PostgreSQL version 12 ou antérieure redémarre automatiquement pour appliquer la rotation des mots de passe pendant la période de maintenance de 60 à 90 jours.

  • 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 for 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 for PostgreSQL exécute une version de PostgreSQL antérieure à 14.1. RDS for PostgreSQL prend en charge les réplicas en lecture en cascade sur RDS for PostgreSQL version 14.1 et versions ultérieures uniquement. Pour plus d’informations, consultez Utilisation de réplicas en lecture en cascade avec RDS for PostgreSQL.

  • 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 for PostgreSQL. Pour plus d’informations, consultez Promotion d'un réplica en lecture en instance de bases de données autonome.

  • Si vous promouvez une réplique de lecture PostgreSQL à partir d'une chaîne de réplication (une série de répliques de lecture en cascade), toutes les répliques de lecture en aval existantes continuent de recevoir automatiquement les fichiers WAL de l'instance promue. Pour plus d’informations, consultez Utilisation de réplicas en lecture en cascade avec RDS for PostgreSQL.

  • 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 for 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 for PostgreSQL antérieures à 14.1. Les sauvegardes automatiques pour les réplicas en lecture sont prises en charge pour RDS for PostgreSQL 14.1 et versions ultérieures uniquement. Pour RDS for PostgreSQL 13 et versions antérieures, créez un instantané à partir d'un réplica en lecture si vous souhaitez en obtenir une sauvegarde.

  • oint-in-time La restauration P (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, veuillez consulter la section Restauration d'une instance de base de données à une date spécifiée.

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 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 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 plus d’informations, consultez Utilisation de réplicas en lecture en cascade avec RDS for PostgreSQL. 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 plus d’informations, consultez Création d'un réplica en lecture.

Vous pouvez créer des répliques de lecture pour votre instance de base de données RDS pour PostgreSQL de la même manière 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. 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 for PostgreSQL.

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éplicas en lecture RDS for PostgreSQL ont accès à des bases de données externes disponibles via des encapsuleurs de données externes (FDW) 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 FDW pris en charge incluent oracle_fdw, postgres_fdw et tds_fdw. Pour plus d’informations, consultez Utilisation des encapsuleurs de données externes pris en charge pour Amazon RDS for PostgreSQL.

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 d'instances de base de données multi-AZ.

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. Dans ce 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.

  • 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 Processus de basculement pour Amazon RDS. 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.

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.

Utilisation de réplicas en lecture en cascade avec RDS for PostgreSQL

À partir de la version 14.1, RDS for 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 for 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 for 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 for 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 for PostgreSQL source. Par exemple, supposons que vous disposez d'une instance de base de données RDS for PostgreSQL 14.1, rpg-db-main. Vous pouvez effectuer les actions 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 for 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 for PostgreSQL. Commencez par créer le réplica en lecture, puis activez les sauvegardes automatiques sur l'instance de base de données RDS for PostgreSQL. Le processus est le même que pour les autres moteurs de base de données Amazon RDS. Pour plus d’informations, consultez Création d'un réplica en lecture.

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 instance de base de données en lecture/écriture 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.

Note

Pour les réplicas en lecture en cascade, RDS for 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.

Fonctionnement de la réplication en continu pour différentes versions de RDS for PostgreSQL

Comme indiqué dans Configuration de réplicas en lecture avec PostgreSQL, RDS for 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 for PostgreSQL.

Dans la région Entre régions
PostgreSQL 14.1 and higher versions

  • Emplacements de réplication

  • Archive Amazon S3

  • Emplacements de réplication
PostgreSQL 13 and lower versions

  • Archive Amazon S3

  • Emplacements de réplication

Pour plus d’informations, consultez Surveillance et réglage du processus de réplication.

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_wal_senders

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 pour RDS for PostgreSQL 13 et versions ultérieures est 20. 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_wal_senders dans la documentation PostgreSQL.

wal_keep_segments

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éplication.

Note

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 de plus amples informations, veuillez consulter wal_keep_segments et wal_keep_size dans la documentation PostgreSQL.

max_slot_wal_keep_size

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 for 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 for PostgreSQL.

Pour de plus amples informations sur ce paramètre, consultez 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 la réplique lue en utilisant les données WAL archivées d'Amazon S3 ou en utilisant les données WAL associées au slot 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 for 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 identifiants de transaction, 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_connections

  • max_worker_processes

  • max_wal_senders

  • max_prepared_transactions

  • max_locks_per_transaction

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 for 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, veuillez consulter CloudWatch Métriques Amazon pour Amazon RDS.

  • 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 for PostgreSQL

Toutes les versions de RDS for PostgreSQL utilisent des emplacements de réplication pour les réplicas en lecture entre régions. RDS for 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 for 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 lost états unreserved et ne wal_status sont visibles que lorsqu'ils ne max_slot_wal_keep_size sont pas négatifs.

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 : répertorie l'emplacement qui a le plus de latence, c'est-à-dire celui qui est le plus éloigné du réplica principal. Cette latence peut être associée au réplica en lecture mais également à la connexion.

  • 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 Pour de plus amples informations sur la surveillance de la réplication en continu sur vos instances de base de données RDS for PostgreSQL, consultez Best practices for Amazon RDS PostgreSQL replication sur AWS Database Blog.

Résolution des problèmes liés à la réplication en lecture de RDS pour PostgreSQL

Vous trouverez ci-dessous des idées pour résoudre certains problèmes courants liés à la réplication en lecture de RDS pour PostgreSQL.

Mettre fin à la requête à l'origine du décalage de lecture de la réplique

Les transactions actives ou inactives en état de transaction qui s'exécutent depuis longtemps dans la base de données peuvent interférer avec le processus de réplication WAL, augmentant ainsi le délai de réplication. Veillez donc à surveiller le temps d'exécution de ces transactions avec 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 d'y mettre fin.

Exécutez une requête sur l'instance principale similaire à la suivante pour mettre fin à la requête en cours d'exécution depuis longtemps :

SELECT pg_terminate_backend(PID);