- Amazon Relational Database Service
Pages non validesIncohérence de l'indexTaux de transaction exceptionnellement élevé

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.

Cette section explore d'autres raisons qui peuvent empêcher l'utilisation de l'aspirateur de progresser. Ces problèmes ne sont actuellement pas directement identifiables par la postgres_get_av_diag() fonction.

Pages non valides

Une erreur de page non valide se produit lorsque PostgreSQL détecte une incompatibilité dans le checksum 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 inscrite 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éterminer le 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 du pg_database système.

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

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 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 pg_classdocumentation de PostgreSQL pour connaître tous les types d'objets pris en charge, indiqués par relkind la colonne dans. pg_class

Orientations

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'CONCURRENTLYoption — Avant la version 12 de PostgreSQL, la reconstruction d'un index nécessitait un verrou de table exclusif, limitant ainsi l'accès à la table. Avec PostgreSQL version 12 et versions ultérieures, cette option permet le verrouillage au niveau CONCURRENTLY des lignes, ce qui améliore considérablement la disponibilité de la table. Voici la commande :

    REINDEX INDEX ix_name CONCURRENTLY;

    Bien qu'elle CONCURRENTLY soit moins perturbatrice, elle peut être plus lente sur des tables très occupées. Si possible, envisagez de créer l'indice pendant les périodes de faible trafic.

    Pour plus d'informations, consultez la documentation PostgreSQL REINDEX.

  • À l'aide de l'INDEX_CLEANUP FALSEoption — Si les index sont volumineux et qu'on estime qu'il faut beaucoup de temps pour les terminer, vous pouvez débloquer Autovacuum en exécutant un manuel VACUUM FREEZE tout en excluant les index. Cette fonctionnalité est disponible dans PostgreSQL version 12 et versions ultérieures.

    Le contournement des index vous permettra d'éviter le processus d'élimination de l'index incohérent et d'atténuer le problème d'encapsulation. Toutefois, cela ne résoudra pas le problème sous-jacent de page non valide. Pour résoudre complètement le problème de page non valide, vous devez 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 :

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' AWS assistance.

Incohérence de l'index

Un indice logiquement incohérent peut empêcher l'autovacuum de progresser. Les erreurs suivantes ou des erreurs similaires sont enregistrées pendant la phase de vide 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

Orientations

Reconstruisez l'index ou ignorez les index en utilisant INDEX_CLEANUP le manuelVACUUM FREEZE. Pour plus d'informations sur la façon de reconstruire l'index, voir Si le type d'objet est un index.

  • Utilisation de l'option CONCURRENTLY : avant la version 12 de PostgreSQL, la reconstruction d'un index nécessitait un verrouillage de table exclusif, limitant ainsi l'accès à la table. Avec la version 12 de PostgreSQL et les versions 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;

    CONCURRENTLY est moins perturbateur, mais il peut être plus lent lorsque les tables sont occupées. Si possible, envisagez de créer l'indice pendant les périodes de faible trafic. Pour plus d'informations, consultez REINDEX dans la documentation de PostgreSQL.

  • À l'aide de l'option INDEX_CLEANUP FALSE : si les index sont volumineux et qu'on estime qu'ils nécessitent beaucoup de temps pour être terminés, vous pouvez débloquer l'autovacuum en exécutant un VACUUM FREEZE manuel tout en excluant les index. Cette fonctionnalité est disponible dans PostgreSQL version 12 et versions ultérieures.

    Le contournement des index vous permettra d'éviter le processus d'élimination de l'index incohérent et d'atténuer le problème d'encapsulation. Toutefois, cela ne résoudra pas le problème sous-jacent de page non valide. Pour résoudre complètement le problème de page non valide, vous devez 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 d'Autovacuum, ce qui ralentit le nettoyage des tuples morts et augmente le risque d'encapsulation des identifiants de transaction. Vous pouvez surveiller le taux de transaction en mesurant la différence max(age(datfrozenxid)) entre deux périodes, généralement par seconde. En outre, vous pouvez utiliser les indicateurs de compteur suivants de RDS Performance Insights pour mesurer le taux de transaction (la 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 Autovacuum, provoquant un gonflement, des problèmes de verrouillage et des problèmes de performances potentiels. Cela peut avoir un impact négatif sur le processus d'aspiration automatique 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 du système L'ensemble du système est peut-être surchargé, ce qui rend difficile pour 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 suivre ses tâches :

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

  2. Ciblez des tables fréquemment mises à jour avec un VACUUM FREEZE fonctionnement manuel tous les soirs, toutes les semaines ou toutes les deux semaines en dehors des heures de pointe.

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