PostgreSQL accumulation de WAL et saturation du disque dues à un slot de réplication logique inactif

Jacob Kirin 0 Points de réputation
2026-09-21T09:46:09.5033333+00:00

Nous constatons une forte pression sur l'espace disque de notre cluster PostgreSQL primaire, provoquée par l'accumulation de fichiers WAL. L'analyse indique la présence d'un slot de réplication logique inactif dont le confirmed_flush_lsn est bloqué, ce qui empêche le nettoyage automatique du répertoire pg_wal. Quelle est la procédure recommandée pour identifier et supprimer en toute sécurité ce slot orphelin via pg_drop_replication_slot(), et comment s'assurer que les processus actifs ou en arrière-plan ne créent pas de conflits lors de la suppression ?

Windows pour les entreprises | Client Windows pour les professionnels de l’informatique | Services d’annuaire | Active Directory
0 commentaires Aucun commentaire

1 réponse

Trier par : Le plus utile
  1. Domic Vo 34,165 Points de réputation Conseiller(ère) indépendant(e)
    2026-09-21T10:19:30.38+00:00

    Bonjour,

    Votre diagnostic est correct : l’accumulation des fichiers WAL dans pg_wal est due à un slot de réplication logique inactif dont le confirmed_flush_lsn n’avance plus. PostgreSQL ne peut pas nettoyer les WAL tant qu’un slot logique déclare en avoir besoin. La procédure recommandée consiste à identifier précisément le slot orphelin, vérifier qu’aucun processus actif ne l’utilise, puis le supprimer avec pg_drop_replication_slot().

    Commencez par lister les slots existants avec :

    sql

    SELECT slot_name, plugin, active, restart_lsn, confirmed_flush_lsn 
    FROM pg_replication_slots;
    

    Un slot logique inactif apparaîtra avec active = false et un confirmed_flush_lsn bloqué. Avant de le supprimer, assurez-vous qu’aucun processus de réplication ou de consommation logique n’est en cours. Vous pouvez vérifier les connexions actives avec :

    sql

    SELECT pid, usename, application_name, state 
    FROM pg_stat_activity 
    WHERE backend_type = 'walsender';
    

    Si aucun processus n’est lié au slot en question, vous pouvez le supprimer en toute sécurité :

    sql

    SELECT pg_drop_replication_slot('nom_du_slot');
    

    Cette commande libère immédiatement les WAL retenus par ce slot. Il est important de ne jamais supprimer un slot actif, car cela provoquerait une perte de continuité pour le consommateur logique associé. Si vous avez un doute, arrêtez temporairement les services applicatifs qui pourraient utiliser la réplication logique, puis relancez-les après suppression du slot.

    Pour éviter que la situation ne se reproduise, je recommande de mettre en place une surveillance régulière des slots via pg_replication_slots et d’automatiser la détection des slots inactifs. Dans les environnements où les slots logiques sont créés dynamiquement, il est préférable de définir une politique interne de nettoyage ou d’utiliser des outils comme pglogical qui gèrent mieux la durée de vie des slots.

    DV.

    Cette réponse vous a-t-elle été utile?

    0 commentaires Aucun commentaire

Votre réponse

Les réponses peuvent être marquées comme « Acceptées » par l’auteur(e) de la question et « Recommandées » par les modérateurs, ce qui aide les utilisateurs à savoir que la réponse a résolu le problème de l’auteur(e).