Utilisation de réplicas en lecture pour Amazon RDS for PostgreSQL - Amazon Relational Database Service

Utilisation de réplicas en lecture pour Amazon RDS for PostgreSQL

Vous pouvez mettre à l'échelle les lectures de votre instance de base de données Amazon RDS for PostgreSQL en ajoutant des réplicas en lecture à l'instance. Comme pour les autres moteurs de base de données Amazon RDS, RDS for 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.

Ensuite, vous trouverez des informations propres à l'utilisation des réplicas en lecture avec RDS for 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 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 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 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.

  • La récupération ponctuelle (PITR) n'est pas prise en charge pour les réplicas 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 à 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'à cinq réplicas en lecture à partir d'une seule instance de base de données source. 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é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éplicas en lecture dans des Régions AWS différentes de celles de l'instance de 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'un réplica en lecture dans une 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 de durée de vie (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.

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.

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 le réplica en lecture à l'aide des données WAL archivées d'Amazon S3 ou en utilisant 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 for PostgreSQL exécutant PostgreSQL version 12.9 dans la même Région AWS que la base de données source, les emplacements de réplication ne sont donc 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

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 délai de réplication représente la durée, en millisecondes, pendant laquelle un réplica en lecture retarde 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 replica_lag

    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 retard de réplication dans Amazon CloudWatch en consultant la métrique Amazon RDS ReplicaLag. Pour en savoir plus sur ReplicaLag et d'autres métriques pour Amazon RDS, veuillez consulter Métriques Amazon CloudWatch 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 métriques susceptibles de prévoir les problèmes de réplication. Plutôt que d'analyser directement le journal PostgreSQL, vous pouvez utiliser Amazon CloudWatch pour consulter 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.

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 métriques suivantes :

  • 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 for PostgreSQL, veuillez consulter 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.