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

Utilisation de réplicas en lecture PostgreSQL dans Amazon RDS

Vous utilisez généralement des réplicas en lecture pour configurer la réplication entre instances de base de données Amazon RDS. Pour obtenir des informations générales sur les réplicas en lecture, veuillez consulter Utilisation des réplicas en lecture.

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

Configuration de réplicas en lecture avec PostgreSQL

Amazon RDS PostgreSQL utilise la réplication de streaming native de PostgreSQL pour créer une copie en lecture seule d'une instance de bases de données source. Cette instance de base de données de réplica en lecture (« instance de secours » dans le jargon de PostgreSQL) est une réplication physique créée 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. PostgreSQL diffuse de manière asynchrone les modifications de base de données sur cette connexion au fur et à mesure qu'elles sont effectuées.

PostgreSQL utilise un rôle de « réplication » pour effectuer la réplication de streaming. Ce rôle dispose de privilèges, mais ne peut pas être utilisé pour modifier des données. PostgreSQL utilise un processus unique pour traiter la réplication.

Afin que votre instance de base de données puisse être utilisée comme instance de base de données source, vous devez configurer les sauvegardes automatiques sur cette instance de base de données source. Pour cela, vous devez définir la période de rétention des sauvegardes sur une valeur autre que 0.

Vous pouvez créer un réplica en lecture PostgreSQL sans affecter l'instance de base de données source et les utilisateurs de la source. Amazon RDS définit les paramètres et autorisations nécessaires pour l'instance de base de données source et le réplica en lecture sans interruption de service. Un instantané de l'instance de base de données source est pris, et devient le réplica en lecture. Aucune interruption de service ne se produit lorsque vous supprimez un réplica en lecture.

Vous pouvez créer jusqu'à cinq réplicas en lecture à partir d'une seule instance de base de données source. 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, faites-le é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 instances de base de données PostgreSQL utilisent une connexion sécurisée que vous pouvez chiffrer en définissant le paramètre ssl sur 1 pour les instances de la source et du réplica en lecture.

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, mais vous ne pouvez pas utiliser un réplica de secours multi-AZ pour alimenter le trafic en lecture. À la place, vous pouvez 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.

Si l'instance de base de données source d'un déploiement Multi-AZ bascule vers l'instance de secours, tous les réplicas en lecture associés se mettent automatiquement à utiliser l'instance de secours (désormais principale) comme source de réplication. La nouvelle instance principale a une adresse IP différente de celle de son prédécesseur. Par conséquent, dans certains cas, les réplicas en lecture redémarrent après un basculement afin qu'ils puissent se synchroniser avec la nouvelle instance principale. C'est le cas pour toutes les versions de PostgreSQL antérieures à PostgreSQL 13. Pour PostgreSQL 13 et les versions ultérieures, le redémarrage n'est pas nécessaire.

Note

La modification d'une classe d'instance de base de données ou la modification d'un nom d'instance de base de données modifie également l'adresse IP de l'instance. Avant PostgreSQL 13, de telles modifications nécessitaient le redémarrage de l'instance de base de données.

Pour plus d'informations sur les déploiements Multi-AZ, veuillez consulter Déploiements d'instances de base de données multi-AZ. Pour obtenir des informations sur le mécanisme de basculement, veuillez consulter 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.

Vous pouvez créer un réplica en lecture en tant qu'instance de base de données Multi-AZ. Amazon RDS crée une instance de secours de votre réplica dans une autre zone de disponibilité (AZ) pour la prise en charge du basculement pour le réplica. 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.

Si vous utilisez l'extension postgres_fdw pour accéder aux données à partir d'un serveur distant, le réplica en lecture a également accès au serveur distant. Pour plus d'informations sur l'utilisation de postgres_fdw, consultez Utilisation de l'extension postgres_fdw pour accéder à des données externes.

Surveillance des réplicas en lecture PostgreSQL

Pour vos réplicas en lecture RDS for PostgreSQL, vous pouvez surveiller le délai de réplication dans Amazon CloudWatch en observant la métrique Amazon RDS ReplicaLag. Le délai de réplication représente la durée, en millisecondes, pendant laquelle un réplica en lecture retarde l'instance de base de données source. La métrique ReplicaLag contient la valeur de SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS replica_lag.

Pour en savoir plus sur ReplicaLag et d'autres métriques pour Amazon RDS, veuillez consulter Métriques Amazon CloudWatch pour Amazon RDS.

Limites des réplicas en lecture avec PostgreSQL

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

  • Chaque réplica en lecture PostgreSQL est en lecture seule. Vous ne pouvez pas transformer un réplica en lecture en réplica accessible en écriture.

  • Vous ne pouvez pas créer un réplica en lecture à partir d'un autre réplica en lecture. Par conséquent, vous ne pouvez pas créer de réplicas en lecture en cascade.

  • Vous pouvez promouvoir un réplica en lecture PostgreSQL comme nouvelle instance de base de données source. Néanmoins, le réplica en lecture ne devient pas automatiquement la nouvelle instance de base de données source. Le réplica en lecture, lorsqu'il est promu, arrête de recevoir les communications WAL (write-head log) et cesse d'être une instance en lecture seule. Veillez à configurer toute réplication que vous souhaitez conserver, car le réplica en lecture promu est, à présent, une nouvelle instance de base de données source.

  • En l'absence de transactions utilisateur sur l'instance de base de données source, un réplica en lecture PostgreSQL consigne un retard de réplication qui peut atteindre cinq minutes.

  • Vous ne pouvez pas activer les sauvegardes automatiques pour les réplicas en lecture PostgreSQL.

Interruption de réplication avec les réplicas en lecture PostgreSQL

Plusieurs paramètres PostgreSQL contrôlent le processus de réplication. Dans certaines situations, ils peuvent interrompre involontairement la réplication avec un réplica en lecture. Voici quelques exemples :

  • Le paramètre max_wal_senders a une valeur trop basse pour fournir suffisamment de données aux différents réplicas en lecture. Si cela se produit, la réplication s'arrête.

  • Le paramètre wal_keep_segments spécifie le nombre de fichiers journaux WAL (write-head log) à conserver pour fournir les données aux réplicas en lecture. Si vous affectez à ce paramètre une valeur trop basse, vous pouvez entraîner un tel retard du réplica en lecture que la réplication de streaming s'arrête. Dans ce cas, Amazon RDS signale une erreur de réplication. RDS commence ensuite la récupération des données sur le réplica en lecture en relisant les journaux WAL archivés de l'instance de base de données source. 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 de streaming. Pour plus d'informations, consultez Résolution des problèmes de réplica en lecture PostgreSQL.

  • Le paramètre max_slot_wal_keep_size définit la taille maximale des fichiers WAL que les emplacements de réplication sont autorisés à conserver dans le répertoire pg_wal à l'heure du point de contrôle. S max_slot_wal_keep_size est -1 (valeur par défaut), les emplacements de réplication peuvent conserver un nombre illimité de fichiers WAL. Sinon, le valeur restart_lsn d'un emplacement de réplication peut être inférieure au numéro de séquence de journal (LSN) actuel de plus que la taille donnée. Si tel est le cas, il se peut que le serveur en veille utilisant l'emplacement ne puisse plus continuer la réplication en raison de la suppression des fichiers WAL requis. Vous pouvez voir la disponibilité WAL des emplacements de réplication dans pg_replication_slots.

Lorsque le flux WAL qui fournit les données à un réplica en lecture est interrompu, PostgreSQL bascule en mode de récupération. Il restaure le réplica en lecture à l'aide de fichiers WAL archivés d'Amazon S3. Quand ce processus terminé, PostgreSQL tente de rétablir la réplication de streaming.

Résolution des problèmes de réplica en lecture PostgreSQL

La façon de résoudre les problèmes de réplica en lecture PostgreSQL diffère en fonction de quelques facteurs. Il s'agit de la version de RDS for PostgreSQL que vous exécutez et de si la réplication se déroule entre les Régions AWS ou au sein de la même Région :

  • Commençons par PostgreSQL version 9.5.2. RDS for PostgreSQL utilise des emplacements de réplication physiques pour gérer la rétention WAL (write ahead log) sur chaque instance de base de données source entre les Régions AWS.

  • Depuis RDS for PostgreSQL 14.1 et versions ultérieures, les emplacements de réplication physique sont utilisés pour les réplicas entre Régions et également dans la même Région.

Pour résoudre les problèmes de réplication lorsque des emplacements de réplication physique sont utilisés, veuillez consulter Réplicas en lecture et emplacements de réplication physiques. Les informations de cette section s'appliquent aux réplicas en lecture dans la même Région pour RDS for PostgreSQL 14.1 et versions ultérieures. Elles s'appliquent également aux réplicas en lecture entre Régions pour RDS for PostgreSQL 9.5.2 et versions ultérieures (mais antérieures à PostgreSQL 14.1).

Pour résoudre les problèmes de réplication pouvant être causés par vos paramètres PostgreSQL, veuillez consulter Réplicas en lecture et paramètres WAL.

Réplicas en lecture et paramètres WAL

Comme mentionné dans Interruption de réplication avec les réplicas en lecture PostgreSQL, la valeur du paramètre PostgreSQL wal_keep_segments peut interrompre la réplication si elle est trop faible. La valeur définie pour ce paramètre spécifie le nombre de journaux à conserver. Si la valeur est trop faible, un réplica en lecture peut prendre un retard tel que la réplication du streaming s'arrête. Dans ce cas, Amazon RDS signale une erreur de réplication et commence la récupération sur le réplica en lecture en relisant les journaux WAL archivés de l'instance de base de données source. 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 de streaming.

Le journal PostgreSQL du réplica en lecture capture le processus, comme indiqué dans cet exemple. La ligne en gras montre qu'Amazon RDS a récupéré un réplica en lecture qui a pris du retard et a perdu le contact avec le réplica primaire, 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 fichiers WAL archivés sur le réplica pour qu'il rattrape son retard, le streaming vers le réplica en lecture peut reprendre. Lorsque PostgreSQL reprend le streaming, il é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

Le journal PostgreSQL capture d'autres informations importantes que vous pouvez utiliser pour résoudre les problèmes de réplica en lecture. Par exemple, à 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 seront recyclés au cours d'une période donnée, et régler le paramètre wal_keep_segments au besoin. 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 wal_keep_segments de 32 n'est pas suffisante pour suivre le rythme de l'activité de streaming, et nous vous recommandons d'augmenter la valeur de ce paramètre.

Par ailleurs, si la charge de travail sur votre instance de base de données génère une grande quantité de données WAL, vous devrez peut-être modifier la classe d'instance de base de données de votre instance de base de données et du réplica en lecture sources. La modification de cette classe d'instance avec des performances réseau élevées (10 Gbit/s) aide le réplica à suivre la source. Pour en savoir plus sur le débit auquel les données WAL sont générées par votre charge de travail, vérifiez la métrique TransactionLogsGeneration Amazon CloudWatch.

Réplicas en lecture et emplacements de réplication physiques

Les emplacements de réplication physiques sont utilisés depuis RDS for PostgreSQL 9.5.2 pour gérer la rétention WAL (write ahead log) sur l'instance de base de données source pour les réplicas en lecture entre Régions. Depuis RDS for PostgreSQL 14.1, les emplacements de réplication physiques sont également utilisés dans une Région AWS pour gérer la rétention WAL. Pour chaque réplica en lecture, Amazon RDS crée et associe un emplacement physique de réplication qui contient les données WAL. Les emplacements de réplication physiques permettent une récupération plus rapide que les fichiers journaux archivés d'Amazon S3. L'objectif est donc de garantir que votre instance de base de données RDS for PostgreSQL les utilise lorsque cela est possible pour assurer une récupération rapide.

Vous pouvez utiliser deux métriques Amazon CloudWatch pour vous aider à gérer les emplacements physiques :

  • OldestReplicationSlotLag : répertorie le réplica qui a le plus de décalage, c'est-à-dire qui est le plus éloigné du réplica primaire

  • 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 vérifier le statut d'un emplacement de réplication physique pour un réplica en lecture, vous pouvez exécuter la requête pg_replication_slots sur l'instance source, comme dans l'exemple suivant.

postgres=#select * from pg_replication_slots; slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restart_lsn _______________________________________________________________________________________________________________________________________________ rds_us_east_1_db_uzwlholddgpblksce6hgw4nkte | | physical | | | t | 12598 | | | 4E/95000060 (1 row)

Comme indiqué dans Interruption de réplication avec les réplicas en lecture PostgreSQL, la valeur du paramètre max_slot_wal_keep_size a un effet sur le processus de réplication. Par défaut, ce paramètre a une valeur de -1, ce qui permet aux emplacements de réplication de conserver un nombre illimité de fichiers WAL. Vous pouvez modifier cette valeur par une valeur spécifique, mais sachez qu'une fois que votre instance de base de données a atteint cette valeur, ses emplacements ne peuvent plus contenir de journaux WAL. Le comportement de votre instance de base de données Amazon RDS si le paramètre max_slot_wal_keep_size atteint une limite dépend de si la réplication est pour des réplicas en lecture dans une Région ou entre Régions :

  • Pour les réplicas dans une Région, si la limite de max_slot_wal_keep_size est atteinte, Amazon RDS utilise les journaux d'archivage d'Amazon S3 jusqu'à ce qu'il rattrape la source. Il peut ensuite reprendre le streaming. Pour éviter cela, vous pouvez surveiller vos emplacements de réplication physiques et ajuster le paramètre max_slot_wal_keep_size pour minimiser le besoin de fichiers journaux d'archivage.

  • Pour les réplicas entre Régions, si la limite de max_slot_wal_keep_size est atteinte, la réplication s'arrête. Les journaux d'archivage ne sont pas utilisés. Soyez donc prudent si vous ajustez le paramètre max_slot_wal_keep_size pour les réplicas en lecture entre Régions.