Explication des messages NOTICE dans RDS pour PostgreSQL

La fonction postgres_get_av_diag() fournit les messages NOTICE suivants :

Lorsque l’âge n’a pas encore atteint le seuil de surveillance

Le seuil de surveillance postgres_get_av_diag() pour identifier les bloqueurs est de 500 millions de transactions par défaut. Si postgres_get_av_diag() génère le message NOTICE suivant, l’âge de la transaction n’a pas encore atteint ce seuil.

NOTICE: postgres_get_av_diag() checks for blockers that prevent aggressive vacuums only, it does so only after exceeding dvb_threshold which is 500,000,000 and age of this PostgreSQL cluster is currently at 2.

Non connecté à la base de données dont l’ID de transaction est le plus ancien

La fonction postgres_get_av_diag() fournit le résultat le plus précis lorsqu’elle est connectée à la base de données dont l’ID de transaction est le plus ancien. La base de données dont l’âge de l’ID de transaction est le plus ancien indiqué par postgres_get_av_diag() sera différente de « my_database » dans votre cas. Si vous n’êtes pas connecté à la bonne base de données, le message NOTICE suivant est généré :

NOTICE: You are not connected to the database with the age of oldest transaction ID. Connect to my_database database and run postgres_get_av_diag() for accurate reporting.

Il est important de se connecter à la base de données dont l’âge de la transaction est le plus ancien pour les raisons suivantes :

• Identification des bloqueurs de tables temporaires : les métadonnées des tables temporaires étant spécifiques à chaque base de données, elles se trouvent généralement dans la base de données dans laquelle elles ont été créées. Toutefois, si une table temporaire se trouve être le principal bloqueur et qu’elle se trouve dans la base de données contenant la transaction la plus ancienne, cela peut prêter à confusion. La connexion à la base de données appropriée garantit l’identification précise du bloqueur de table temporaire.

• Diagnostic des vacuums lents : les métadonnées d’index et les informations relatives au nombre de tables sont spécifiques à chaque base de données et sont nécessaires pour diagnostiquer les problèmes de lenteur du vacuum.

La base de données dont l’âge de la transaction est le plus ancien se trouve sur une base de données rdsadmin ou template0

Dans certains cas, les bases de données rdsadmin ou template0 peuvent être identifiées comme étant celles dont l’ID de transaction est le plus ancien. Dans ce cas, postgres_get_av_diag() émet le message NOTICE suivant :

NOTICE: The database with the age of oldest transaction ID is rdsadmin or template0, reach out to support if the reported blocker is in rdsadmin or template0.

Vérifiez que le bloqueur répertorié ne provient d’aucune de ces deux bases de données. Si la présence du bloqueur est signalée dans rdsadmin ou template0, contactez le support, car ces bases de données ne sont pas accessibles aux utilisateurs et nécessitent une intervention.

Il est très peu probable que la base de données rdsadmin ou template0 contienne un bloqueur principal.

Lorsqu’un vacuum agressif est déjà en cours d’exécution

La fonction postgres_get_av_diag() est conçue pour signaler lorsqu’un processus de vacuum agressif est en cours d’exécution, mais elle ne déclenche cette sortie que lorsque le vacuum est actif depuis au moins 1 minute. Ce délai intentionnel contribue à réduire les risques de faux positifs. En attendant, la fonction garantit que seuls les vacuums efficaces et significatifs sont signalés, ce qui permet une surveillance plus précise et plus fiable de l’activité du vacuum.

La fonction postgres_get_av_diag() génère le message NOTICE suivant lorsqu’elle détecte un ou plusieurs vacuums agressifs en cours.

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.

Comme indiqué dans le message NOTICE, continuez à surveiller les performances du vacuum. Pour plus d’informations sur le vacuum agressif, consultez Un vacuum agressif (pour éviter tout bouclage) est en cours d’exécution

Lorsque l’autovacuum est désactivé

La fonction postgres_get_av_diag() génère le message NOTICE suivant si l’autovacuum est désactivé sur votre instance de base de données :

NOTICE: Autovacuum is OFF, we strongly recommend to enable it, no restart is necessary.

L’autovacuum est une fonctionnalité essentielle de votre instance de base de données RDS pour PostgreSQL. Elle garantit le bon fonctionnement de la base de données. Elle supprime automatiquement les anciennes versions de lignes, récupère de l’espace de stockage et évite le gonflement des tables, ce qui contribue à garantir l’efficacité des tables et des index pour des performances optimales. En outre, elle protège contre le bouclage des ID de transaction, qui peut interrompre les transactions sur votre instance Amazon RDS. La désactivation de l’autovacuum peut entraîner une baisse à long terme des performances et de la stabilité de la base de données. Nous vous conseillons de laisser cette fonctionnalité activée en permanence. Pour plus d’informations, consultez Présentation d’autovacuum dans les environnements RDS pour PostgreSQL.

Note

La désactivation de l’autovacuum n’arrête pas les vacuums agressifs. Ils se produiront toujours une fois que vos tables auront atteint le seuil autovacuum_freeze_max_age.

Le nombre de transactions restantes est extrêmement faible

La fonction postgres_get_av_diag() génère le message NOTICE suivant lorsqu’un vacuum de bouclage est imminent. Ce message NOTICE est émis lorsque votre instance Amazon RDS est à 100 millions de transactions avant que de nouvelles transactions ne soient potentiellement rejetées.

WARNING: Number of transactions remaining is critically low, resolve issues with autovacuum or perform manual VACUUM FREEZE before your instance stops accepting transactions.

Une action immédiate est nécessaire pour éviter toute durée d’indisponibilité de la base de données. Vous devez surveiller de près vos opérations de vacuum et envisager de lancer manuellement une opération VACUUM FREEZE sur la base de données concernée afin d’éviter les échecs de transaction.