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écupération de l’espace de table via une opération de vacuum

PostgreSQL Multiversion Concurrency Control (MVCC) permet de préserver l’intégrité des données en enregistrant une copie interne des lignes mises à jour ou supprimées jusqu’à ce qu’une transaction soit validée ou annulée. Ces copies, également appelées tuples, peuvent provoquer un gonflement de la table si elles ne sont pas nettoyées régulièrement. Les instances PostgreSQL ordonnent les transactions selon leurs ID de transaction, et PostgreSQL utilise un modèle MVCC basé sur les ID de transaction pour déterminer la visibilité des tuples et assurer l’isolation des transactions. Chaque transaction établit un instantané des données, et chaque tuple possède une version. L’instantané et la version sont tous deux basés sur l’ID de transaction.

Pour nettoyer les données, l’utilitaire VACUUMexécute quatre fonctions clés dans PostgreSQL :

Comme dans MVCC, l’opération de vacuum dans Aurora PostgreSQL est basée sur l’ID de transaction. Si une transaction est en cours lorsque le l’opération de vacuum commence, les lignes qui sont toujours visibles pour cette transaction ne sont pas supprimées.

Pour plus d’informations sur l’utilitaire VACUUM, consultez VACUUM dans la documentation PostgreSQL. Pour plus d’informations sur la prise en charge de VACUUM dans Aurora PostgreSQL Limitless Database, consultez VACUUM.

AUTOVACUUM

Aurora PostgreSQL utilise les utilitaires VACUUM et AUTOVACUUM pour supprimer les tuples inutiles. Le mécanisme sous-jacent de l’AUTOVACUUM et du VACUUM manuel sont les mêmes ; la seule différence réside dans l’automatisation.

AUTOVACUUM dans Aurora PostgreSQL et Aurora PostgreSQL Limitless Database est une combinaison des utilitaires VACUUM et ANALYZE. AUTOVACUUM détermine les bases de données et les tables à nettoyer, selon une règle prédéfinie, telle que le pourcentage de tuples inactifs et le nombre d’insertions.

Par exemple, AUTOVACUUM « se réveille » périodiquement pour effectuer un nettoyage. L’intervalle est contrôlé par le paramètre autovacuum_naptime. La valeur par défaut est de 1 minute. Les valeurs par défaut des paramètres de configuration AUTOVACUUM et VACUUM sont les mêmes dans Aurora PostgreSQL Limitless Database et Aurora PostgreSQL.

Le démon AUTOVACUUM, s’il est activé, émet automatiquement des commandes ANALYZE chaque fois que le contenu d’une table a suffisamment changé. Dans Aurora PostgreSQL Limitless Database, AUTOVACUUM émet une command ANALYZE sur les routeurs et les partitions.

Pour plus d’informations sur le démon AUTOVACUUM et les paramètres de stockage des tables associés à AUTOVACUUM, consultez Le démon autovacuum et les Paramètres de stockage dans la documentation PostgreSQL.

Vacuum basé sur le temps dans Aurora PostgreSQL Limitless Database

Aurora PostgreSQL Limitless Database est un système distribué, ce qui signifie que plusieurs instances peuvent être impliquées dans une transaction. Par conséquent, la visibilité basée sur l’ID de transaction ne s’applique pas. Aurora PostgreSQL Limitless Database utilise à la place un mécanisme de visibilité basé sur le temps, car les ID de transaction ne sont pas unifiés entre les instances, tandis que le temps, lui, peut l’être. Chaque instantané de transaction et chaque version de tuple se réfèrent au temps plutôt qu’à l’ID de transaction. Plus précisément, chaque instantané de transaction est associé à une heure de début, et chaque tuple enregistre une heure de création (au moment d’une INSERT ou d’une UPDATE) ainsi qu’une heure de suppression (au moment d’une DELETE).

Pour maintenir la cohérence des données entre les instances du groupe de partitions de base de données, Aurora PostgreSQL Limitless Database doit s’assurer que l’opération de vacuum ne supprime aucun tuple encore visible pour les transactions actives du groupe de partitions de base de données. Par conséquent, les opérations de vacuum sont également basées sur le temps dans Aurora PostgreSQL Limitless Database. D’autres aspects de VACUUM demeurent inchangés, notamment le fait que, pour exécuter VACUUM sur une table donnée, l’utilisateur doit disposer d’un accès à cette table.

L’exemple suivant illustre le fonctionnement des opérations de vacuum basées sur le temps.

La dernière étape est réalisée par le biais d’une synchronisation, afin que toutes les partitions soient informées de la transaction 1, même si celle-ci ne les concerne pas toutes.

Utilisation des statistiques de base de données pour l’opération de vacuum

Pour obtenir des informations sur les tuples susceptibles de nécessiter un nettoyage, utilisez la vue limitless_stat_all_tables, qui fonctionne de la même manière que pg_stat_all_tables. L’exemple suivant illustre l’interrogation de la vue.

SELECT * FROM rds_aurora.limitless_stat_all_tables WHERE relname LIKE '%customer%';

De même, pour les statistiques de base de données, utilisez limitless_stat_database au lieu de pg_stat_database, et limitless_stat_activity plutôt que pg_stat_activity.

Pour vérifier l’utilisation du disque de la table, utilisez la fonction limitless_stat_relation_sizes, qui fonctionne de la même manière que pg_relation_size. Les exemples suivants illustrent l’interrogation de la fonction.

SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public','customer');

Pour suivre la progression d’une opération VACUUM sur Aurora PostgreSQL Limitless Database, utilisez la vue limitless_stat_progress_vacuum au lieu de pg_stat_progress_vacuum. L’exemple suivant illustre l’interrogation de la vue.

SELECT * FROM rds_aurora.limitless_stat_progress_vacuum;

Pour plus d’informations, consultez Vues d’Aurora PostgreSQL Limitless Database et Fonctions d’Aurora PostgreSQL Limitless Database.

Différences dans le comportement des opérations de vacuum entre Aurora PostgreSQL et Aurora PostgreSQL Limitless Database

Les différences suivantes distinguent également Aurora PostgreSQL et Aurora PostgreSQL Limitless Database en ce qui concerne le processus de vacuum :

Pour plus d’informations sur la prise en charge de VACUUM dans Aurora PostgreSQL Limitless Database, consultez VACUUM dans le Référence Aurora PostgreSQL Limitless Database.