Réplication avec Amazon Aurora PostgreSQL

Vous trouverez ci-dessous des informations sur la réplication avec Amazon Aurora PostgreSQL, notamment sur la manière de surveiller la réplication.

Rubriques

• Utilisation de réplicas Aurora
• Amélioration de la disponibilité en lecture des réplicas Aurora
• Surveillance de la réplication Aurora PostgreSQL
• Utilisation de la réplication logique PostgreSQL avec Aurora

Utilisation de réplicas Aurora

Les réplicas Aurora sont les points de terminaison indépendants d'un cluster de bases de données Aurora, utilisés de préférence pour la mise à l'échelle des opérations de lecture et l'augmentation de la disponibilité. Un cluster de base de données Aurora peut inclure jusqu'à 15 répliques Aurora situées dans les zones de disponibilité de la AWS région du cluster de base de données Aurora.

Le volume de cluster de bases de données est composé de plusieurs copies des données du cluster de bases de données. Cependant, les données du volume de cluster sont représentées comme un seul volume logique à l'instance principale en écriture et aux réplicas Aurora du cluster de bases de données. Pour plus d'informations sur les réplicas Aurora, consultez Réplicas Aurora.

Les réplicas Aurora fonctionnement parfaitement pour le dimensionnement en lecture, car ils sont intégralement dédiés aux opérations de lecture du volume de votre cluster. L'instance de base de données en écriture gère les opérations d'écriture. Le volume du cluster est partagé entre toutes les instances de votre cluster de base de données Aurora PostgreSQL. Ainsi, aucun travail supplémentaire n'est nécessaire pour répliquer une copie des données pour chaque réplica Aurora.

Avec Aurora PostgreSQL, quand un réplica Aurora est supprimé, le point de terminaison de son instance est supprimé immédiatement et le réplica Aurora est supprimé du point de terminaison du lecteur. S'il y a des instructions qui s'exécutent sur le réplica Aurora en cours de suppression, une période de grâce de trois minutes est accordée. Les instructions existantes peuvent se terminer élégamment pendant la période de grâce. Lorsque la période de grâce se termine, le réplica Aurora est arrêté et supprimé.

Les clusters de base de données Aurora PostgreSQL prennent en charge les répliques Aurora dans AWS différentes régions, à l'aide de la base de données globale Aurora. Pour de plus amples informations, veuillez consulter Utilisation de bases de données globales Amazon Aurora.

Note

Avec la fonctionnalité de disponibilité de lecture améliorée, si vous voulez redémarrer les réplicas Aurora dans le cluster de bases de données, vous devez le faire manuellement. Pour les clusters de bases de données créés avant cette fonction, le redémarrage de l'instance de base de données d'écriture redémarre automatiquement les réplicas Aurora. Le redémarrage automatique ré-établit un point d'entrée qui garantit la cohérence en lecture/écriture à travers le cluster de base de données.

Amélioration de la disponibilité en lecture des réplicas Aurora

Aurora PostgreSQL améliore la disponibilité en lecture dans le cluster de bases de données en répondant en continu aux demandes de lecture lorsque l'instance de base de données d'écriture redémarre ou lorsque le réplica Aurora n'est pas en mesure de suivre le trafic d'écriture.

La fonction de disponibilité en lecture est disponible par défaut sur les versions suivantes d'Aurora PostgreSQL :

• Versions 15.2 et 15 ultérieures

• Versions 14.7 et 14 ultérieures

• Versions 13.10 et 13 ultérieures

• Versions 12.14 et 12 ultérieures

Pour utiliser la fonction de disponibilité en lecture pour un cluster de bases de données créé sur l'une de ces versions avant ce lancement, redémarrez l'instance d'écriture du cluster de bases de données.

Lorsque vous modifiez les paramètres statiques de votre cluster de bases de données Aurora PostgreSQL, vous devez redémarrer l'instance d'enregistreur pour que les modifications des paramètres soient prises en compte. Par exemple, vous devez redémarrer l'instance d'écriture lorsque vous définissez la valeur de shared_buffers. Grâce à la disponibilité améliorée des réplicas Aurora, le cluster de bases de données maintient la disponibilité en lecture pendant ces redémarrages, ce qui réduit l'impact des modifications apportées à l'instance d'écriture. Les instances de lecture ne redémarrent pas et continuent de répondre aux demandes de lecture. Pour appliquer les modifications de paramètres statiques, redémarrez chaque instance de lecteur individuelle.

Le réplica Aurora d'un cluster de bases de données Aurora PostgreSQL peut remédier à des erreurs de réplication telles que le redémarrage du rédacteur, le basculement, la lenteur de la réplication et les problèmes de réseau en rétablissant rapidement l'état de la base de données en mémoire après la reconnexion avec le rédacteur. Cette approche permet aux instances des réplicas Aurora d'être cohérentes avec les dernières mises à jour de stockage alors que la base de données client est toujours disponible.

Les transactions en cours qui entrent en conflit avec la restauration de la réplication peuvent recevoir une erreur, mais le client peut réessayer ces transactions une fois que les lecteurs s'alignent sur le rédacteur.

Surveillance des réplicas Aurora

Vous pouvez surveiller les réplicas Aurora lorsque vous récupérez à la suite d'une déconnexion du rédacteur. Utilisez les métriques ci-dessous pour vérifier les informations les plus récentes concernant l'instance de lecteur et pour suivre les transactions en lecture seule en cours de traitement.

• La aurora_replica_status fonction est mise à jour pour renvoyer le maximum up-to-date d'informations pour l'instance de lecteur lorsqu'elle est toujours connectée. L'horodatage de la dernière mise à jour dans aurora_replica_status est toujours vide pour la ligne correspondant à l'instance de base de données sur laquelle la requête est exécutée. Cela indique que l'instance de lecteur possède les données les plus récentes.

• Lorsque le réplica Aurora se déconnecte de l'instance de rédacteur puis se reconnecte, l'événement de base de données suivant est émis :

  Read replica has been disconnected from the writer instance and reconnected.

• Lorsqu'une requête en lecture seule est annulée en raison d'un conflit de récupération, le message d'erreur suivant peut s'afficher dans le journal des erreurs de la base de données :

  Canceling statement due to conflict with recovery.

Limites

Les réplicas Aurora avec disponibilité améliorée sont soumis aux limitations suivantes :

• Les répliques Global DB Aurora dans le secondaire Régions AWS ne sont pas prises en charge.

• Les réplicas Aurora ne prennent pas en charge la récupération de la réplication en ligne si celle-ci est déjà en cours et doit redémarrer.

• Les réplicas Aurora redémarrent quand votre instance de base de données approche du renvoi à la ligne de l'ID de transaction. Pour plus d'informations sur le renvoi à la ligne de l'ID de transaction, consultez Prévention des échecs de renvoi à la ligne de l'ID de transaction.

• Les réplicas Aurora peuvent redémarrer lorsque le processus de réplication est bloqué dans certaines circonstances.

Surveillance de la réplication Aurora PostgreSQL

Le dimensionnement en lecture et la haute disponibilité dépendent d'un temps de retard minimal. Vous pouvez surveiller le retard d'une réplique Aurora par rapport à l'instance de base de données Writer de votre cluster de bases de données Aurora PostgreSQL en surveillant la métrique Amazon. CloudWatch ReplicaLag Comme les réplicas Aurora lisent à partir du même volume de cluster que l'instance de base de données en écriture, la métrique ReplicaLag a une signification différente pour un cluster de bases de données Aurora PostgreSQL. La métrique ReplicaLag d'un réplica Aurora indique le retard du cache de page du réplica Aurora par rapport à celui de l'instance de base de données en écriture.

Pour plus d'informations sur la surveillance des instances et des CloudWatch métriques RDS, consultezSurveillance des métriques d'un cluster de bases de données Amazon Aurora.