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éduction du gonflement des tables et des index avec l’extension pg\$1repack Vous pouvez utiliser l’extension `pg_repack` pour éliminer le gonflement des tables et des index comme alternative à `VACUUM FULL`. Cette extension est prise en charge sur RDS pour PostgreSQL versions 9.6.3 et ultérieures. Pour plus d'informations sur l'`pg_repack`extension et le réemballage complet de la table, consultez la [documentation du GitHub projet](https://reorg.github.io/pg_repack/). Contrairement à cela`VACUUM FULL`, l'`pg_repack`extension ne nécessite un lock exclusif (AccessExclusiveLock) que pendant une courte période lors de l'opération de reconstruction de la table dans les cas suivants : + Création initiale de la table de journal : une table de journal est créée pour enregistrer les modifications survenues lors de la copie initiale des données, comme indiqué dans l’exemple suivant : ``` postgres=>\dt+ repack.log_* List of relations -[ RECORD 1 ]-+---------- Schema | repack Name | log_16490 Type | table Owner | postgres Persistence | permanent Access method | heap Size | 65 MB Description | ``` + swap-and-dropPhase finale. Pour le reste de l’opération de reconstruction, il suffit d’un verrou `ACCESS SHARE` sur la table d’origine pour copier des lignes de celle-ci vers la nouvelle table. Cela permet aux opérations INSERT, UPDATE et DELETE de se dérouler comme d’habitude. ## Recommandations Les recommandations suivantes s’appliquent lorsque vous supprimez le gonflement des tables et des index à l’aide de l’extension `pg_repack` : + Effectuez le reconditionnement en dehors des heures ouvrables ou pendant une fenêtre de maintenance afin de minimiser son impact sur les performances des autres activités de base de données. + Surveillez de près les sessions bloquantes pendant l'activité de reconstruction et assurez-vous qu'aucune activité sur la table d'origine ne risque de bloquer`pg_repack`, en particulier pendant la swap-and-drop phase finale lorsqu'un verrouillage exclusif de la table d'origine est nécessaire. Pour plus d’informations, consultez [Identification de ce qui bloque une requête](https://repost.aws/knowledge-center/rds-aurora-postgresql-query-blocked). Lorsque vous rencontrez une session bloquante, vous pouvez y mettre fin à l’aide de la commande suivante après un examen attentif. Cela permet la poursuite de `pg_repack` pour terminer la reconstruction : ``` SELECT pg_terminate_backend(pid); ``` + Lors de l’application des modifications accumulées à partir de la table de journal `pg_repack's` sur des systèmes présentant un taux de transactions très élevé, le processus d’application risque de ne pas être en mesure de suivre le rythme des modifications. Dans de tels cas, `pg_repack` ne serait pas en mesure de terminer le processus d’application. Pour de plus amples informations, veuillez consulter [Surveillance de la nouvelle table lors du reconditionnement](#Appendix.PostgreSQL.CommonDBATasks.pg_repack.Monitoring). Si les index sont très gonflés, une autre solution consiste à effectuer un reconditionnement des index uniquement. Cela permet également aux cycles de nettoyage des index du VACUUM de se terminer plus rapidement. Vous pouvez ignorer la phase de nettoyage de l’index à l’aide du VACUUM manuel de PostgreSQL version 12, et elle est automatiquement ignorée lors de l’autovacuum d’urgence à partir de PostgreSQL version 14. Cela permet au VACUUM de se terminer plus rapidement sans supprimer le gonflement de l’index et cette solution est uniquement destinée aux situations d’urgence, telles que la prévention du VACUUM de bouclage. Pour plus d’informations, consultez [Prévention du gonflement dans les index](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html#AuroraPostgreSQL.diag-table-ind-bloat.AvoidinginIndexes) dans le Guide de l’utilisateur Amazon Aurora. ## Conditions préalables + La table doit avoir une contrainte PRIMARY KEY ou UNIQUE non nulle. + La version de l’extension doit être la même pour le client et le serveur. + Assurez-vous que l’instance RDS a plus de `FreeStorageSpace` que la taille totale de la table sans le gonflement. Par exemple, considérez que la taille totale de la table, y compris TOAST et les index, est de 2 To, et que le gonflement total de la table est de 1 To. La valeur de `FreeStorageSpace` requise doit être supérieure à la valeur renvoyée par le calcul suivant : `2TB (Table size)` - `1TB (Table bloat)` = `1TB` Vous pouvez utiliser la requête suivante pour vérifier la taille totale de la table et utiliser `pgstattuple` pour en déduire le gonflement. Pour plus d’informations, consultez [Diagnostic du gonflement de la table et de l’index](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html) dans le Guide de l’utilisateur Amazon Aurora. ``` SELECT pg_size_pretty(pg_total_relation_size('table_name')) AS total_table_size; ``` Cet espace est récupéré une fois l’activité terminée. + Assurez-vous que l’instance RDS dispose d’une capacité de calcul et d’E/S suffisante pour gérer l’opération de reconditionnement. Vous pouvez envisager d’augmenter verticalement la classe d’instance pour un équilibre optimal des performances. **Pour utiliser l’extension `pg_repack`** 1. Installez l’extension `pg_repack` sur votre instance de base de données RDS pour PostgreSQL en exécutant la commande suivante. ``` CREATE EXTENSION pg_repack; ``` 1. Exécutez les commandes suivantes pour accorder l’accès en écriture aux tables de journal temporaires créées par `pg_repack`. ``` ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT INSERT ON TABLES TO PUBLIC; ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT USAGE, SELECT ON SEQUENCES TO PUBLIC; ``` 1. Connectez-vous à la base de données à l’aide de l’utilitaire client `pg_repack`. Utilisez un compte qui possède les privilèges `rds_superuser`. Par exemple, supposons que le rôle `rds_test` a les privilèges `rds_superuser`. La syntaxe suivante effectue une opération `pg_repack` pour les tables complètes, y compris tous les index de table de la base de données `postgres`. ``` pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test -k postgres ``` **Note** Vous devez vous connecter à l’aide de l’option -k. L’option -a n’est pas prise en charge. La réponse du client `pg_repack` fournit des informations sur les tables de l’instance de base de données qui sont reconditionnées. ``` INFO: repacking table "pgbench_tellers" INFO: repacking table "pgbench_accounts" INFO: repacking table "pgbench_branches" ``` 1. La syntaxe suivante reconditionne une seule table `orders` qui inclut les index de la base de données `postgres`. ``` pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders -k postgres ``` La syntaxe suivante reconditionne uniquement les index de la table `orders` dans la base de données `postgres`. ``` pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders --only-indexes -k postgres ``` ## Surveillance de la nouvelle table lors du reconditionnement + La taille de la base de données est augmentée de la taille totale de la table moins le surchargement, jusqu'à la swap-and-drop phase de reconditionnement. Vous pouvez surveiller le taux de croissance de la taille de la base de données, calculer la vitesse du reconditionnement et estimer approximativement le temps nécessaire pour terminer le transfert de données initial. Par exemple, considérez que la taille totale de la table est de 2 To, la taille de la base de données de 4 To et le gonflement total de la table de 1 To. La valeur de taille totale de la base de données renvoyée par le calcul à la fin de l’opération de reconditionnement est la suivante : `2TB (Table size)` \$1 `4 TB (Database size)` - `1TB (Table bloat)` = `5TB` Vous pouvez estimer approximativement la vitesse de l’opération de reconditionnement en échantillonnant le taux de croissance en octets entre deux points dans le temps. Si le taux de croissance est de 1 Go par minute, l’opération initiale de création de table peut prendre environ 1 000 minutes ou 16,6 heures. Outre la création initiale de la table, `pg_repack` doit également appliquer les modifications accumulées. Le temps nécessaire dépend du taux d’application des modifications en cours et des modifications accumulées. **Note** Vous pouvez utiliser l’extension `pgstattuple` pour calculer le gonflement dans la table. Pour plus d’informations, consultez [pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html). + Le nombre de lignes de la table de journal `pg_repack's`, sous le schéma de reconditionnement, représente le volume de modifications en attente d’être appliquées à la nouvelle table après le chargement initial. Vous pouvez consulter la table de journal `pg_repack's` dans `pg_stat_all_tables` pour surveiller les modifications appliquées à la nouvelle table. `pg_stat_all_tables.n_live_tup` indique le nombre d’enregistrements en attente d’être appliqués à la nouvelle table. Pour plus d’informations, consultez [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW). ``` postgres=>SELECT relname,n_live_tup FROM pg_stat_all_tables WHERE schemaname = 'repack' AND relname ILIKE '%log%'; -[ RECORD 1 ]--------- relname | log_16490 n_live_tup | 2000000 ``` + Vous pouvez utiliser l’extension `pg_stat_statements` pour connaître le temps nécessaire à chaque étape de l’opération de reconditionnement. Cela est utile pour préparer l’application de la même opération de reconditionnement dans un environnement de production. Vous pouvez ajuster la clause `LIMIT` pour étendre davantage la sortie. ``` postgres=>SELECT SUBSTR(query, 1, 100) query, round((round(total_exec_time::numeric, 6) / 1000 / 60),4) total_exec_time_in_minutes FROM pg_stat_statements WHERE query ILIKE '%repack%' ORDER BY total_exec_time DESC LIMIT 5; query | total_exec_time_in_minutes -----------------------------------------------------------------------+---------------------------- CREATE UNIQUE INDEX index_16493 ON repack.table_16490 USING btree (a) | 6.8627 INSERT INTO repack.table_16490 SELECT a FROM ONLY public.t1 | 6.4150 SELECT repack.repack_apply($1, $2, $3, $4, $5, $6) | 0.5395 SELECT repack.repack_drop($1, $2) | 0.0004 SELECT repack.repack_swap($1) | 0.0004 (5 rows) ``` Le reconditionnement est une out-of-place opération complète, de sorte que la table d'origine n'est pas affectée et nous ne prévoyons aucun problème inattendu nécessitant la restauration de la table d'origine. Si le reconditionnement échoue de façon inattendue, vous devez rechercher la cause de l’erreur et la résoudre. Une fois le problème résolu, supprimez et recréez l’extension `pg_repack` dans la base de données où se trouve la table, puis recommencez l’étape `pg_repack`. En outre, la disponibilité des ressources informatiques et l’accessibilité simultanée de la table jouent un rôle crucial dans la réalisation en temps voulu de l’opération de reconditionnement.