Configuration de réplicas en lecture avec PostgreSQL - Amazon Relational Database Service

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.

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 de plus amples informations, veuillez consulter Utilisation de réplicas en lecture en cascade avec RDS pour 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 de plus amples informations, veuillez consulter 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é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'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 pour 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épliques de lecture RDS pour PostgreSQL ont accès à des bases de données externes disponibles via des wrappers de données étrangers FDWs () sur l'instance de base de données source. Par exemple, supposons que votre instance de base de données RDS for PostgreSQL utilise l'encapsuleur mysql_fdw pour accéder aux données de RDS for MySQL. Si tel est le cas, vos réplicas en lecture peuvent également accéder à ces données. Les autres supports pris en charge FDWs incluent oracle_fdwpostgres_fdw, ettds_fdw. Pour de plus amples informations, veuillez consulter Utilisation des encapsuleurs de données externes pris en charge pour Amazon RDS pour 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 de l’instance de base de données multi-AZ pour Amazon RDS.

Si l'instance de base de données source d'un déploiement multi-AZ bascule vers une instance de secours, les réplicas en lecture associés se mettent automatiquement à utiliser l'instance de secours (désormais principale) comme source de réplication. Les réplicas en lecture ont peut-être besoin d'être redémarrés, en fonction de la version de RDS for PostgreSQL, comme suit :

  • PostgreSQL 13 et versions ultérieures – Le redémarrage n'est pas obligatoire. Les réplicas en lecture sont automatiquement synchronisés avec la nouvelle instance principale. Toutefois, dans certains cas, votre application cliente risque de mettre en cache les détails du service DNS (Domain Name Service) pour vos réplicas en lecture. Si tel est le cas, définissez la valeur time-to-live (TTL) sur moins de 30 secondes. Cela empêche le réplica en lecture de conserver une adresse IP obsolète (et l'empêche ainsi de se synchroniser avec la nouvelle instance principale). Pour en savoir plus et pour obtenir d'autres bonnes pratiques, consultez Directives opérationnelles de base Amazon RDS.

  • PostgreSQL 12 et toutes les versions antérieures – Les réplicas en lecture redémarrent automatiquement après un basculement vers le réplica de secours car ce dernier (désormais principal) a une adresse IP différente et un nom d'instance différent. Le redémarrage synchronise le réplica en lecture avec la nouvelle instance principale.

Pour en savoir plus sur le basculement, consultez Basculement d’une instance de base de données multi-AZ pour Amazon RDS. 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.