Amazon Relational Database Service
Guide de l'utilisateur

Utilisation de réplicas en lecture PostgreSQL

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, consultez Utilisation des réplicas en lecture.

Cette section contient des informations spécifiques sur l'utilisation des réplicas en lecture dans PostgreSQL.

Configuration de réplicas en lecture avec PostgreSQL

Amazon RDS PostgreSQL 9.3.5 et les versions ultérieures utilisent 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 (« instance principale » dans le jargon propre à PostgreSQL). Cette instance de bases 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 bases de données principale. Elle est créée par une connexion spéciale qui transmet les données WAL (write-ahead log) entre l'instance de bases de données source et le réplica en lecture, avec PostgreSQL qui diffuse en continu de façon asynchrone les modifications de base de données au fur et à mesure qu'elles sont apporté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.

Avant qu'une instance de bases de données puisse servir d'instance de bases de données source, vous devez activer les sauvegardes automatiques sur l'instance de bases de données source en affectant à la période de rétention des sauvegardes une valeur différente de 0.

La création d'un réplica en lecture PostgreSQL ne nécessite pas de coupure pour l'instance de base de données principale. Amazon RDS définit les paramètres et les autorisations nécessaires pour l'instance de base de données source et le réplica en lecture sans aucune interruption de service. Un instantané est pris de l'instance de bases de données source, et cet instantané 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 bases 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 bases de données source. Si vous dimensionnez l'instance de bases de données source, vous devez également dimensionner les réplicas en lecture.

Amazon RDS remplace tout paramètre incompatible sur un réplica en lecture s'il empêche le réplica en lecture 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 que dans le réplica en lecture. Dans ce cas, Amazon RDS met à jour le paramètre dans le réplica en lecture pour qu'il possède la même valeur que celle de l'instance de base de données source.

Les instances de bases de données PostgreSQL utilisent une connexion sécurisée que vous pouvez chiffrer en affectant au paramètre ssl la valeur 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 bases de données mono-AZ ou Multi-AZ. Vous utilisez des déploiements multi-AZ pour améliorer la durabilité et la disponibilité des données critiques, mais vous ne pouvez pas utiliser une instance secondaire multi-AZ pour servir les requêtes en lecture seule. À 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 source d'un déploiement multi-AZ bascule vers l'instance secondaire, tous les réplicas en lecture associés se mettent automatiquement à utiliser l'instance secondaire (désormais principale) comme source de réplication. Pour plus d'informations, consultez Haute disponibilité (multi-AZ) pour Amazon RDS.

Vous pouvez désormais 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é 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 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 aura également accès au serveur distant. Pour plus d'informations sur l'utilisation de postgres_fdw, consultez Accès aux données externes à l'aide de l'extension postgres_fdw.

Surveillance des réplicas en lecture PostgreSQL

Pour les réplicas en lecture PostgreSQL, vous pouvez surveiller le retard de réplication dans Amazon CloudWatch en consultant la métrique Amazon RDS ReplicaLag. La métrique ReplicaLag contient la valeur de SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS slave_lag.

Limites des réplicas en lecture avec PostgreSQL

Voici les limites des réplicas en lecture pour PostgreSQL :

  • Chaque réplica en lecture PostgreSQL est accessible en lecture seule et il est impossible de le rendre accessible en écriture.

  • Vous ne pouvez pas créer un réplica en lecture à partir d'un autre réplica en lecture (ainsi, vous ne pouvez pas créer des réplicas en lecture en cascade).

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

  • Un réplica en lecture PostgreSQL consigne une latence de réplication pouvant atteindre jusqu'à cinq minutes si aucune transaction utilisateur ne se produit sur l'instance de base de données source.

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

Dans plusieurs situations, une instance de bases de données source PostgreSQL peut interrompre involontairement la réplication avec un réplica en lecture. Ces situations incluent les suivantes :

  • Le paramètre max_wal_senders a une valeur trop basse pour fournir suffisamment de données aux différents réplicas en lecture. Cette situation entraîne l'arrêt de la réplication.

  • Le paramètre PostgreSQL wal_keep_segments, indique le nombre de fichiers WAL à conserver pour fournir les données aux réplicas en lecture. La valeur de ce paramètre spécifie le nombre de journaux à conserver. 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 et commence la récupération des données sur le réplica en lecture en relisant les journaux WAL archivés de l'instance de bases de données source. Ce processus de récupération continue 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 Dépannage d'un problème de réplica en lecture PostgreSQL.

  • Un réplica en lecture PostgreSQL exige un redémarrage si le point de terminaison de l'instance de bases de données source change.

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

Dépannage d'un problème de réplica en lecture PostgreSQL

PostgreSQL utilise des emplacements de réplication pour la réplication entre régions. C'est pourquoi le processus de dépannage des problèmes de réplication diffère selon qu'il s'agit d'une même région ou de régions différentes.

Dépannage des problèmes de réplica en lecture PostgreSQL au sein d'une même région AWS

Le paramètre PostgreSQL, wal_keep_segments, indique le nombre de fichiers WAL (Write Ahead Log) à conserver pour fournir les données aux réplicas en lecture. La valeur de ce paramètre spécifie le nombre de journaux à conserver. 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 et commence la récupération des données sur le réplica en lecture en relisant les journaux WAL archivés de l'instance de bases de données source. Ce processus de récupération continue jusqu'à ce que le réplica en lecture ait rattrapé suffisamment de retard pour continuer la réplication de streaming.

Le journal PostgreSQL sur le réplica en lecture indique quand Amazon RDS récupère un réplica en lecture présentant cet état en relisant les fichiers WAL archivés.

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

Après un certain délai, Amazon RDS relit suffisamment de fichiers WAL archivés sur le réplica pour rattraper le retard et permettre au réplica en lecture de recommencer le streaming. PostgreSQL reprend alors le streaming et écrit une ligne similaire à la suivante dans le fichier journal.

2014-11-07 19:41:36 UTC::@:[24714]:LOG:  started streaming WAL from primary at 1B/B6000000 on timeline 1

Vous pouvez déterminer le nombre de fichiers WAL que vous devez conserver en examinant les informations de point de contrôle dans le journal. Le journal PostgreSQL indique les informations suivantes à chaque point de contrôle. En examinant les fichiers journaux des transactions « # recycled » de ces instructions de journalisation, vous pouvez comprendre combien de fichiers de transaction seront recyclées au cours d'une période et peut utiliser ces informations pour ajuster le paramètre wal_keep_segments.

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

Par exemple, supposons que le journal PostgreSQL montre que 35 fichiers sont recyclés à partir des déclarations de journaux « vérification terminée » dans un délai de 5 minutes. Dans ce cas, nous savons qu'avec ce motif d'utilisation un réplica en lecture s'appuie sur 35 fichiers de transactions en cinq minutes. Un réplica de lecture ne peut pas survivre cinq minutes dans un état de non-streaming si l'instance de base de données source est définie à la valeur du paramètre wal_keep_segments par défaut de 32.

Dépannage des problèmes de réplica en lecture PostgreSQL entre plusieurs régions AWS

PostgreSQL (versions 9.4.7 et 9.5.2 exclusivement) utilise des emplacements physiques de réplication pour gérer la rétention WAL(Write Ahead Log) sur l'instance de bases de données source. Pour chaque instance de réplica en lecture entre régions, Amazon RDS crée et associe un emplacement physique de réplication. Vous pouvez utiliser deux métriques Amazon CloudWatch, Oldest Replication Slot Lag et Transaction Logs Disk Usage, pour connaître le retard du dernier réplica en termes de données WAL reçues et le volume de stockage utilisé pour les données WAL. La valeur Transaction Logs Disk Usage peut considérablement augmenter lorsqu'un réplica en lecture entre régions présente un retard important.

Si la charge de travail sur votre instance de bases de données génère une grande quantité de données WAL, vous devrez peut-être modifier la classe d'instance de bases de données de votre instance de bases de données source et de votre instance de bases de données de réplica en lecture. Dans ce cas, vous la modifiez en une classe présentant des performances réseau élevées (10 Go/s) pour que le réplica s'adapte. La métrique Amazon CloudWatch Transaction Logs Generation peut vous aider à comprendre le débit auquel les données WAL sont générées par votre charge de travail.

Pour déterminer le statut d'un réplica en lecture entre régions, 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)