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 vide identifiables dans

Autovacuum effectue des aspirations agressives et abaisse l'âge de la transaction IDs en dessous du seuil spécifié par le autovacuum_freeze_max_age paramètre de votre instance RDS. Vous pouvez suivre cet âge à l'aide de la CloudWatch métrique AmazonMaximumUsedTransactionIDs.

Pour trouver le paramètre de autovacuum_freeze_max_age (dont la valeur par défaut est de 200 millions de transactions IDs) pour votre instance Amazon RDS, vous pouvez utiliser la requête suivante :

SELECT
    TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age
FROM
    pg_settings
WHERE
    name = 'autovacuum_freeze_max_age';

Notez que les bloqueurs d'aspiration agressifs postgres_get_av_diag() ne sont vérifiés que lorsque leur âge dépasse le seuil de 500 millions de transactions d'aspiration automatique adaptatif d'Amazon RDS. IDs postgres_get_av_diag()Pour détecter les bloqueurs, ceux-ci doivent dater d'au moins 500 millions de transactions.

La postgres_get_av_diag() fonction identifie les types de bloqueurs suivants :

Déclaration active

Dans PostgreSQL, une instruction active est une instruction SQL en cours d'exécution par la base de données. Cela inclut les requêtes, les transactions ou les opérations en cours. Lors de la surveillance viapg_stat_activity, la colonne d'état indique que le processus avec le PID correspondant est actif.

La postgres_get_av_diag() fonction affiche une sortie similaire à la suivante lorsqu'elle identifie une instruction active.

blocker               | Active statement
database              | my_database
blocker_identifier    | SELECT pg_sleep(20000);
wait_event            | Timeout:PgSleep
autovacuum_lagging_by | 568,600,871
suggestion            | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action      | {"SELECT pg_terminate_backend (29621);"}

Action suggérée

En suivant les instructions de la suggestion colonne, l'utilisateur peut se connecter à la base de données dans laquelle l'instruction active est présente et, comme indiqué dans la suggested_action colonne, il est conseillé de revoir attentivement l'option permettant de mettre fin à la session. Si la résiliation est sûre, vous pouvez utiliser la pg_terminate_backend() fonction pour mettre fin à la session. Cette action peut être effectuée par un administrateur (tel que le compte principal RDS) ou par un utilisateur disposant des pg_terminate_backend() privilèges requis.

État Idle in transaction (Transaction inactive)

Une instruction idle in transaction fait référence à toute session qui a ouvert une transaction explicite (par exemple en émettant une BEGIN instruction), effectué un certain travail et attendant maintenant que le client passe plus de travail ou signale la fin de la transaction en émettant un COMMITROLLBACK, ou END (ce qui se traduirait par un impliciteCOMMIT).

La postgres_get_av_diag() fonction affiche une sortie similaire à la suivante lorsqu'elle identifie une idle in transaction instruction en tant que bloqueur.

blocker               | idle in transaction
database              | my_database
blocker_identifier    | INSERT INTO tt SELECT * FROM tt;
wait_event            | Client:ClientRead
autovacuum_lagging_by | 1,237,201,759
suggestion            | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action      | {"SELECT pg_terminate_backend (28438);"}

Action suggérée

Comme indiqué dans la suggestion colonne, vous pouvez vous connecter à la base de données dans laquelle la session de transaction inactive est présente et terminer la session à l'aide de cette pg_terminate_backend() fonction. L'utilisateur peut être votre administrateur (compte principal RDS) ou un utilisateur disposant du pg_terminate_backend() privilège.

Transaction préparée

PostgreSQL autorise les transactions qui font partie d'une stratégie de validation en deux phases appelée transactions préparées. Elles sont activées en réglant le max_prepared_transactions paramètre sur une valeur différente de zéro. Les transactions préparées sont conçues pour garantir qu'une transaction est durable et reste disponible même après une panne de base de données, un redémarrage ou une déconnexion du client. Comme les transactions ordinaires, elles se voient attribuer un identifiant de transaction et peuvent affecter l'autovacuum. S'il est laissé dans un état préparé, l'autovacuum ne peut pas effectuer de congélation et peut entraîner l'encapsulation de l'identifiant de transaction.

Lorsque les transactions sont laissées préparées indéfiniment sans être résolues par un gestionnaire de transactions, elles deviennent des transactions préparées orphelines. La seule façon de résoudre ce problème est de valider ou d'annuler la transaction à l'aide des ROLLBACK PREPARED commandes COMMIT PREPARED or, respectivement.

La postgres_get_av_diag() fonction affiche le résultat suivant lorsqu'elle identifie un bloqueur qui est une transaction préparée.

blocker               | Prepared transaction
database              | my_database
blocker_identifier    | myptx
wait_event            | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion            | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action      | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"}

Action suggérée

Comme indiqué dans la colonne de suggestions, connectez-vous à la base de données où se trouve la transaction préparée. Sur la base de la suggested_action colonne, examinez attentivement s'il faut exécuter l'COMMITune ou l'autreROLLBACK, et quelle est l'action appropriée.

Pour surveiller les transactions préparées en général, PostgreSQL propose une vue de catalogue appelée. pg_prepared_xacts Vous pouvez utiliser la requête suivante pour trouver les transactions préparées.

SELECT
    gid,
    prepared,
    owner,
    database,
    transaction AS oldest_xmin
FROM
    pg_prepared_xacts
ORDER BY
    age(transaction) DESC;

Emplacement de réplication logique

L'objectif d'un slot de réplication est de conserver les modifications non consommées jusqu'à ce qu'elles soient répliquées sur un serveur cible. Pour plus d'informations, consultez la section Réplication logique de PostgreSQL.

Il existe deux types de slots de réplication logiques.

Emplacements de réplication logiques inactifs

Lorsque la réplication est terminée, les journaux de transactions non consommés ne peuvent pas être supprimés et le slot de réplication devient inactif. Bien qu'aucun emplacement de réplication logique inactif ne soit actuellement utilisé par un abonné, il reste sur le serveur, ce qui entraîne la rétention des fichiers WAL et empêche la suppression des anciens journaux de transactions. Cela peut augmenter l'utilisation du disque et empêcher spécifiquement Autovacuum de nettoyer les tables de catalogue internes, car le système doit empêcher le remplacement des informations LSN. Si rien n'est fait, cela peut entraîner une saturation du catalogue, une dégradation des performances et un risque accru de vide global, ce qui peut entraîner une interruption des transactions.

Emplacements de réplication logiques actifs mais lents

Parfois, la suppression des tuples morts du catalogue est retardée en raison de la dégradation des performances de la réplication logique. Ce retard de réplication ralentit la mise à jour du catalog_xmin et peut entraîner un gonflement du catalogue et un vide général.

La postgres_get_av_diag() fonction affiche une sortie similaire à la suivante lorsqu'elle trouve un emplacement de réplication logique en tant que bloqueur.

blocker               | Logical replication slot
database              | my_database
blocker_identifier    | slot1
wait_event            | Not applicable
autovacuum_lagging_by | 1,940,103,068
suggestion            | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action      | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"}

Action suggérée

Pour résoudre ce problème, vérifiez la configuration de réplication afin de détecter tout problème lié au schéma cible ou aux données susceptibles de mettre fin au processus d'application. Les raisons les plus courantes sont les suivantes :

Si le problème est lié à des problèmes d'infrastructure :

Si votre instance est en dehors du AWS réseau ou est activée AWS EC2, consultez votre administrateur pour savoir comment résoudre les problèmes liés à la disponibilité ou à l'infrastructure.

Supprimer le slot inactif

Après avoir confirmé que le slot de réplication n'est plus nécessaire, supprimez-le pour permettre à Autovacuum de continuer. Cette condition active = 'f' garantit que seul un emplacement inactif est supprimé.

SELECT pg_drop_replication_slot('slot1') WHERE active ='f'

Instances de lecteur

Lorsque le paramètre hot_standby_feedback est activé, il empêche l'autovacuum sur l'instance d'écriture de supprimer les lignes mortes qui pourraient encore être nécessaires aux requêtes exécutées sur l'instance de lecteur. Ce comportement est nécessaire car les requêtes exécutées sur l'instance du lecteur (également applicable aux instances du lecteur dans la base de données globale Aurora) nécessitent que ces lignes restent disponibles sur l'instance du rédacteur, ce qui évite les conflits de requêtes et les annulations.

La postgres_get_av_diag() fonction affiche une sortie similaire à la suivante lorsqu'elle trouve une réplique en lecture avec un slot de réplication physique comme bloqueur.

blocker               | Oldest query running on aurora reader
database              | Not applicable
blocker_identifier    | my-aurora-reader-2
wait_event            | Not applicable
autovacuum_lagging_by | 540,122,859
suggestion            | Run the following query on the reader "my-aurora-reader-2" to find the long running query:                                                                                                 
                      | SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 523476310;                                                                                                    
                      | Review carefully and you may consider terminating the query on reader using suggested_action.                                                      
suggested_action      | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 523476310;","                                                                       
                      | [OR]                                                                                                                                                                                    
                      | ","Delete the reader if not needed"}

Comme recommandé dans la suggested_action colonne, examinez attentivement ces options pour débloquer l'autovacuum.

Tables temporaires

Les tables temporaires, créées à l'aide du TEMPORARY mot-clé, résident dans le schéma temporaire, par exemple pg_temp_xxx, et ne sont accessibles qu'à la session qui les a créées. Les tables temporaires sont supprimées à la fin de la session. Cependant, ces tables sont invisibles pour le processus d'aspiration automatique de PostgreSQL et doivent être nettoyées manuellement par la session qui les a créées. Essayer d'aspirer la table des températures d'une autre session n'a aucun effet.

Dans des circonstances exceptionnelles, une table temporaire existe sans qu'elle soit détenue par une session active. Si la session propriétaire se termine de façon inattendue en raison d'un crash fatal, d'un problème réseau ou d'un événement similaire, il est possible que la table temporaire ne soit pas nettoyée et qu'elle soit considérée comme une table « orpheline ». Lorsque le processus Autovacuum de PostgreSQL détecte une table temporaire orpheline, il enregistre le message suivant :

LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"

La postgres_get_av_diag() fonction affiche une sortie similaire à la suivante lorsqu'elle identifie une table temporaire en tant que bloqueur. Pour que la fonction affiche correctement la sortie relative aux tables temporaires, elle doit être exécutée dans la même base de données où ces tables existent.

blocker               | Temporary table
database              | my_database
blocker_identifier    | pg_temp_14.ttemp
wait_event            | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion            | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action      | {"DROP TABLE ttemp;"}

Action suggérée

Suivez les instructions fournies dans la suggestion colonne de sortie pour identifier et supprimer la table temporaire qui empêche l'exécution d'Autovacuum. Utilisez la commande suivante pour supprimer la table temporaire signalée parpostgres_get_av_diag(). Remplacez le nom de la table en fonction de la sortie fournie par la postgres_get_av_diag() fonction.

DROP TABLE my_temp_schema.my_temp_table;

La requête suivante peut être utilisée pour identifier les tables temporaires :

SELECT
    oid,
    relname,
    relnamespace::regnamespace,
    age(relfrozenxid)
FROM
    pg_class
WHERE
relpersistence = 't'
ORDER BY
    age(relfrozenxid) DESC;