Résolution des bloqueurs de vacuum non identifiables dans RDS pour PostgreSQL

Cette section explore d’autres raisons qui peuvent empêcher l’opération de vacuum de progresser. Ces problèmes ne sont actuellement pas directement identifiables par la fonction postgres_get_av_diag().

Pages non valides

Une erreur de page non valide se produit lorsque PostgreSQL détecte une incompatibilité dans le total de contrôle d’une page lors de l’accès à cette page. Le contenu est illisible, ce qui empêche l’autovacuum de geler les tuples. Cela arrête efficacement le processus de nettoyage. L’erreur suivante est écrite dans le journal de PostgreSQL :

WARNING:  page verification failed, calculated checksum YYYYY but expected XXXX
ERROR:  invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT:  automatic vacuum of table myschema.mytable

Détermination du type d’objet

ERROR: invalid page in block 4305910 of relation base/16403/186752608 
WARNING: page verification failed, calculated checksum 50065 but expected 60033

À partir du message d’erreur, le chemin base/16403/186752608 fournit les informations suivantes :

• « base » est le nom du répertoire situé sous le répertoire de données PostgreSQL.

• « 16403 » est l’OID de la base de données, que vous pouvez consulter dans le catalogue système pg_database.

• « 186752608 » est le relfilenode, que vous pouvez utiliser pour rechercher le schéma et le nom de l’objet dans le catalogue système pg_class.

En vérifiant le résultat de la requête suivante dans la base de données concernée, vous pouvez déterminer le type d’objet. La requête suivante récupère les informations d’objet pour l’oid 186752608. Remplacez l’OID par celui correspondant à l’erreur que vous avez rencontrée.

SELECT
    relname AS object_name,
    relkind AS object_type,
    nspname AS schema_name
FROM
    pg_class c
    JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
    c.oid = 186752608;

Pour plus d’informations, consultez la documentation de PostgreSQL pg_class pour connaître tous les types d’objets pris en charge, indiqués par la colonne relkind dans pg_class.

Conseils

La solution la plus efficace à ce problème dépend de la configuration de votre instance Amazon RDS spécifique et du type de données concerné par la page incohérente.

Si le type d’objet est un index :

Il est recommandé de reconstruire l’index.

• Utilisation de l’option CONCURRENTLY : avant PostgreSQL version 12, la reconstruction d’un index nécessitait un verrou de table exclusif, limitant ainsi l’accès à la table. Avec PostgreSQL versions 12 et ultérieures, l’option CONCURRENTLY permet le verrouillage au niveau des lignes, ce qui améliore considérablement la disponibilité de la table. Voici la commande :

  REINDEX INDEX ix_name CONCURRENTLY;

  Bien que l’option CONCURRENTLY soit moins perturbatrice, elle peut être plus lente sur les tables très occupées. Envisagez de générer l’index pendant les périodes de faible trafic si possible.

  Pour plus d’informations, consultez la documentation de PostgreSQL sur REINDEX.

• Utilisation de l’option INDEX_CLEANUP FALSE : si les index sont volumineux et que le temps estimé pour les finaliser est significatif, vous pouvez débloquer l’autovacuum en exécutant une opération VACUUM FREEZE manuelle tout en excluant les index. Cette fonctionnalité est disponible dans PostgreSQL versions 12 et ultérieures.

  Ignorer les index vous permet d’éviter le processus de vacuum de l’index incohérent et d’atténuer le problème de bouclage. Toutefois, cela ne résout pas le problème sous-jacent de page non valide. Pour résoudre complètement le problème de page non valide, vous devrez tout de même reconstruire l’index.

Si le type d’objet est une vue matérialisée :

Si une erreur de page non valide se produit sur une vue matérialisée, connectez-vous à la base de données concernée et actualisez-la pour corriger la page non valide :

Actualisez la vue matérialisée :

REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;

Si l’actualisation échoue, essayez de recréer la vue :

DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;

L’actualisation ou la recréation de la vue matérialisée permet de la restaurer sans affecter les données de la table sous-jacente.

Pour tous les autres types d’objets :

Pour tous les autres types d’objets, contactez l’assistance AWS.

Incohérence de l’index

Un index dont la logique est incohérente peut empêcher l’autovacuum de progresser. Les erreurs suivantes ou des erreurs similaires sont journalisées pendant la phase de vacuum de l’index ou lorsque des instructions SQL accèdent à l’index.

ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name

ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX
CONTEXT:  while vacuuming index index_name of relation schema.table

Conseils

Reconstruisez l’index ou ignorez les index en utilisant INDEX_CLEANUP lors d’une opération VACUUM FREEZE manuelle. Pour plus d’informations sur la façon de reconstruire l’index, consultez Si le type d’objet est un index.

• Utilisation de l’option CONCURRENTLY : avant PostgreSQL version 12, la reconstruction d’un index nécessitait un verrou de table exclusif, limitant ainsi l’accès à la table. Avec PostgreSQL versions 12 et ultérieures, l’option CONCURRENTLY permet le verrouillage au niveau des lignes, ce qui améliore considérablement la disponibilité de la table. Voici la commande :

  REINDEX INDEX ix_name CONCURRENTLY;

  Bien que l’option CONCURRENTLY soit moins perturbatrice, elle peut être plus lente sur les tables très occupées. Envisagez de générer l’index pendant les périodes de faible trafic si possible. Pour plus d’informations, consultez REINDEX dans la documentation de PostgreSQL.

• Utilisation de l’option INDEX_CLEANUP FALSE : si les index sont volumineux et que le temps estimé pour les finaliser est significatif, vous pouvez débloquer l’autovacuum en exécutant une opération VACUUM FREEZE manuelle tout en excluant les index. Cette fonctionnalité est disponible dans PostgreSQL versions 12 et ultérieures.

  Ignorer les index vous permet d’éviter le processus de vacuum de l’index incohérent et d’atténuer le problème de bouclage. Toutefois, cela ne résout pas le problème sous-jacent de page non valide. Pour résoudre complètement le problème de page non valide, vous devrez tout de même reconstruire l’index.

Taux de transaction exceptionnellement élevé

Dans PostgreSQL, les taux de transactions élevés peuvent avoir un impact significatif sur les performances de l’autovacuum, ce qui ralentit le nettoyage des tuples inactifs et augmente le risque de bouclage des ID de transaction. Vous pouvez surveiller le taux de transaction en mesurant la différence de max(age(datfrozenxid)) entre deux périodes, généralement par seconde. En outre, vous pouvez utiliser les métriques de compteur suivantes de RDS Performance Insights pour mesurer le taux de transaction (somme de xact_commit et xact_rollback), qui est le nombre total de transactions.

Compteur	Type	Unité	Métrique
xact_commit	Transactions	Validations par seconde	db.Transactions.xact_commit
xact_rollback	Transactions	Restaurations par seconde	db.Transactions.xact_rollback

Une augmentation rapide indique une charge de transactions élevée, qui peut surcharger l’autovacuum, provoquant un gonflement, des conflits de verrouillage et des problèmes de performances potentiels. Cela peut avoir un impact négatif sur le processus d’autovacuum de plusieurs manières :

• Activité liée à la table : la table en question peut faire l’objet d’un volume élevé de transactions, ce qui peut entraîner des retards.

• Ressources système : l’ensemble du système est peut-être surchargé, ce qui rend difficile pour l’autovacuum d’accéder aux ressources nécessaires pour fonctionner efficacement.

Envisagez les stratégies suivantes pour permettre à l’autovacuum de fonctionner plus efficacement et de mener à bien ses tâches dans le délai imparti :

1. Réduisez le taux de transaction si possible. Envisagez de traiter par lots ou de regrouper les transactions similaires dans la mesure du possible.

2. Ciblez les tables fréquemment mises à jour avec une opération VACUUM FREEZE manuelle tous les soirs, toutes les semaines ou toutes les deux semaines pendant les heures creuses.

3. Envisagez d’augmenter verticalement votre classe d’instance pour allouer davantage de ressources système afin de gérer le volume élevé de transactions et l’autovacuum.