Réplication avec Amazon Aurora Postgre SQL - Amazon Aurora
Réplicas AuroraAmélioration de la disponibilité des réplicas AuroraSurveillance de la réplication

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.

Réplication avec Amazon Aurora Postgre SQL

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

Rubriques

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é du cluster de base de données Aurora AWS Région.

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 SQL base de données Aurora Postgre. 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, lorsqu'une réplique Aurora est supprimée, le point de terminaison de son instance est immédiatement supprimé, et la réplique Aurora est supprimée 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 SQL base de données Aurora Postgre prennent en charge les répliques Aurora de différentes manières AWS Régions, en utilisant la base de données mondiale 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 Postgre SQL améliore la disponibilité en lecture dans le cluster de base de données en traitant en permanence les demandes de lecture lorsque l'instance de base de données d'écriture redémarre ou lorsque la réplique Aurora n'est pas en mesure de suivre le trafic d'écriture.

La fonctionnalité de disponibilité de lecture est disponible par défaut sur les versions suivantes d'Aurora Postgre SQL :

  • 16.1 et toutes les versions supérieures

  • 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

La fonctionnalité de disponibilité en lecture est prise en charge par la base de données globale Aurora dans les versions suivantes :

  • 16.1 et toutes les versions supérieures

  • Version 15.4 et versions 15 ultérieures

  • Version 14.9 et versions 14 ultérieures

  • 13.12 et versions ultérieures 13

  • Versions 12.16 et supérieures 12

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 SQL base de données Aurora Postgre, vous devez redémarrer l'instance du rédacteur pour que les modifications de paramètres prennent effet. 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.

Aurora Replica d'un SQL cluster de base de données Aurora Postgre permet de récupérer des erreurs de réplication telles que le redémarrage de l'enregistreur, le basculement, la lenteur de la réplication et les problèmes de réseau en revenant rapidement à l'état de 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 restauration, un ou plusieurs des messages d'erreur suivants peuvent s'afficher dans le journal des erreurs de base de données :

    Canceling statement due to conflict with recovery.

    User query may not have access to page data to replica disconnect.

    User query might have tried to access a file that no longer exists.

    When the replica reconnects, you will be able to repeat your command.

Limites

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

  • Les répliques Aurora du cluster de base de données secondaire peuvent redémarrer si les données ne peuvent pas être diffusées depuis l'instance du rédacteur pendant la restauration de la réplication.

  • 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 Postgre SQL

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 base de SQL données Aurora Postgre en surveillant la métrique Amazon CloudWatch ReplicaLag. Étant donné que les répliques Aurora sont lues à partir du même volume de cluster que l'instance de base de données du rédacteur, la ReplicaLag métrique a une signification différente pour un cluster de SQL base de données Aurora Postgre. 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 RDS des instances et CloudWatch des métriques, consultezSurveillance des métriques d'un cluster de bases de données Amazon Aurora.