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é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()`. **Topics** + [Pages non valides](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages) + [Incohérence de l’index](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Index_inconsistency) + [Taux de transaction exceptionnellement élevé](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.High_transaction_rate) ## 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 [https://www.postgresql.org/docs/current/catalog-pg-class.html](https://www.postgresql.org/docs/current/catalog-pg-class.html) 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](https://www.postgresql.org/docs/current/sql-reindex.html). + **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' AWS assistance. ## 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](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages). + **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](https://www.postgresql.org/docs/current/sql-reindex.html) dans la documentation de *PostgreSQL*. + **Utilisation de l’option INDEX\$1CLEANUP 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\$1commit et xact\$1rollback), qui est le nombre total de transactions. | Compteur | Type | Unité | Métrique | | --- | --- | --- | --- | | xact\$1commit | Transactions | Validations par seconde | db.Transactions.xact\$1commit | | xact\$1rollback | Transactions | Restaurations par seconde | db.Transactions.xact\$1rollback | 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. 1. 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. 1. 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.