Comment résoudre les problèmes de performance et de connectivité liés à mes réplicas en lecture Aurora compatible avec PostgreSQL ?

Résolution

Identifier et résoudre une latence de réplication

Une latence de réplication se produit lorsqu'il existe un délai entre les opérations d'écriture sur l'instance principale. Bien que les instances Aurora compatibles avec PostgreSQL d'un cluster de bases de données partagent un volume de stockage avec une latence de réplication minimale, un retard peut toujours survenir.

Pour surveiller un retard de réplica, consultez la section Surveillance de la réplication Aurora PostgreSQL.

Gérer les connexions inactives

Un nombre important de connexions de base de données inactives peut entraîner des problèmes de performances et un épuisement des ressources.

Pour résoudre ces problèmes, identifiez et résolvez vos requêtes lentes.

Résoudre les problèmes de configuration liés au basculement

Le mécanisme de basculement automatique d’Aurora compatible avec PostgreSQL priorise la haute disponibilité et peut ne pas maintenir des configurations d'instance spécifiques. Après un événement de basculement, les instances de lecture et d'écriture peuvent échanger des classes d'instance.

Pour vérifier la présence d'événements de basculement, procédez comme suit :

1. Ouvrez la console Amazon Relational Database Service (Amazon RDS).
2. Dans le volet de navigation, choisissez Clusters, puis sélectionnez votre cluster Aurora.
3. Choisissez Journaux et événements.
4. Consultez les journaux pour les événements de basculement récents.

Identifiez l'instance principale actuelle dans la console Amazon RDS pour vérifier si l'instance a échangé des classes d'instance et si elle est maintenant l'instance d'écriture.

Pour restaurer la configuration, vous devez lancer manuellement un basculement.

Procédez comme suit :

1. Ouvrez la console Amazon RDS.
2. Dans le volet de navigation, choisissez Clusters, puis sélectionnez votre cluster Aurora.
3. Sélectionnez Actions, puis Basculement.
4. Sélectionnez une instance qui deviendra la nouvelle instance principale.
5. Remplacez l'instance d'écriture par la classe d'instance de plus grande taille et l'instance de lecture par la classe d'instance de plus petite taille.

Pour éviter les problèmes de configuration après de futurs basculements, effectuez une ou plusieurs des actions suivantes :

• Configurez des alarmes Amazon CloudWatch pour surveiller les événements de basculement.
• Abonnez-vous à une notification d'événement Amazon RDS pour recevoir des notifications en cas de basculement.<br id=hardline_break/> Remarque : vous devez accorder à Amazon RDS les autorisations nécessaires pour publier des notifications sur une rubrique Amazon Simple Notification Service (Amazon SNS).
• Invoquez les fonctions AWS Lambda qui ajustent automatiquement la taille des instances après un événement de basculement.
• Configurez AWS Systems Manager Automation pour créer des flux de travail qui restaurent votre configuration.

Pour une autre solution de basculement, consultez la section Comment un important client financier d’AWS a mis en œuvre la haute disponibilité et la reprise après sinistre rapide pour Amazon Aurora PostgreSQL à l'aide de la base de données globale et du proxy Amazon RDS.

Utiliser la fonctionnalité de disponibilité en lecture d'Aurora PostgreSQL

Utilisez la fonctionnalité de disponibilité en lecture compatible avec Aurora PostgreSQL pour améliorer la disponibilité en lecture lorsque des problèmes d'instance d’écriture surviennent. La fonctionnalité est disponible par défaut sur les versions 16.1+, 15.2+, 14.7+, 13.10+ et 12.14+ d'Aurora PostgreSQL.

Pour plus d'informations, consultez la section Améliorer la disponibilité en lecture des réplicas Aurora.

Informations connexes

Bonnes pratiques relatives à Amazon Aurora PostgreSQL

Haute disponibilité pour Amazon Aurora

Réglage avec les événements d'attente pour Aurora PostgreSQL

Surveillance de la charge de base de données avec Performance Insights sur Amazon RDS