Dépannage d'une activité WAL élevée et gestion de l'espace disque des journaux d'archivage

Dépannage de l'activité WAL élevée et gestion de l'espace disque des journaux d'archivage

Une activité élevée du journal d'écriture anticipée (WAL - Write-Ahead Log) dans PostgreSQL peut être un problème critique, entraînant une consommation rapide de l'espace disque et un potentiel temps d'arrêt de la base de données. Le WAL est le mécanisme de PostgreSQL pour garantir la durabilité et la récupérabilité des données. Chaque modification apportée à votre base de données est d'abord écrite dans le WAL avant d'être appliquée aux fichiers de données. Bien qu'essentiel, une génération excessive de WAL peut rapidement submerger l'espace disque disponible, surtout si les processus d'archivage ou de nettoyage ne sont pas configurés de manière optimale.

Cet article explore les causes courantes d'une génération élevée de WAL et propose des stratégies pratiques pour gérer efficacement l'espace disque des journaux d'archivage. En comprenant les mécanismes sous-jacents et en mettant en œuvre une configuration appropriée, vous pouvez prévenir les pannes liées au disque et maintenir la santé de votre environnement PostgreSQL.

Comprendre le journal d'écriture anticipée (WAL)

Avant de dépanner, il est crucial de comprendre le fonctionnement du WAL. PostgreSQL utilise le WAL pour garantir que les transactions sont atomiques, cohérentes, isolées et durables (ACID). Lorsqu'une modification est apportée à la base de données, un enregistrement décrivant cette modification est écrit dans le tampon WAL, puis vidé dans un fichier WAL sur disque. Cela garantit que même si le serveur plante avant que les pages de données ne soient mises à jour, les modifications peuvent être réappliquées à partir du WAL pendant la récupération.

Les fichiers WAL sont gérés par segments, généralement de 16 Mo par défaut. À mesure que de nouvelles transactions se produisent, de nouveaux fichiers WAL sont créés. Ces fichiers peuvent s'accumuler rapidement et, s'ils ne sont pas gérés correctement (par exemple, archivés et supprimés), ils consommeront tout l'espace disque disponible.

Concepts clés du WAL :

Durabilité : Garantit qu'une fois qu'une transaction est validée, elle survivra aux pannes système.
Réplication : Le WAL est fondamental pour la réplication en flux continu, où les serveurs secondaires reçoivent les enregistrements WAL pour rester synchronisés avec le primaire.
Restauration à un point précis (PITR) : L'archivage WAL est essentiel pour le PITR, vous permettant de restaurer votre base de données à n'importe quel point précis dans le temps.
Segments WAL : Les données WAL sont écrites dans une série de fichiers appelés segments.

Causes courantes d'une activité WAL élevée

Plusieurs facteurs peuvent contribuer à un volume inhabituellement élevé de génération de WAL. Identifier la cause profonde est la première étape d'un dépannage efficace.

1. Chargement et modifications de données en masse

Les opérations telles que INSERT, UPDATE, DELETE, TRUNCATE et COPY peuvent générer une quantité importante de WAL. Les opérations en masse, en particulier sur de grandes tables, produiront naturellement plus d'enregistrements WAL que de petites transactions individuelles.

Exemple : Une seule commande COPY FROM pour insérer des millions de lignes peut générer des gigaoctets de données WAL.
Exemple : Exécution d'une migration de données à grande échelle ou d'un script de mise à jour par lots.

2. Retard de réplication et problèmes de serveur secondaire

Si vos serveurs secondaires ne suivent pas le primaire (retard de réplication), les fichiers WAL s'accumuleront sur le primaire. Le serveur primaire ne peut pas supprimer les segments WAL terminés tant qu'ils n'ont pas été confirmés comme envoyés et traités par tous les serveurs secondaires connectés (si wal_keep_size ou max_slot_wal_keep_size n'est pas configuré, ou si les slots ne sont pas utilisés correctement).

Scénario : Un serveur secondaire est arrêté, déconnecté ou rencontre des problèmes de performance, l'empêchant de consommer les enregistrements WAL du primaire.

3. Appels `fsync` excessifs (moins courant mais possible)

Bien que le WAL lui-même soit le moteur principal, une logique d'application inefficace ou certaines configurations PostgreSQL peuvent entraîner des vidages plus fréquents sur disque, augmentant indirectement l'activité WAL. Cependant, cela est moins courant que les opérations en masse ou les problèmes de réplication.

4. Croissance non gérée du répertoire `pg_wal`

Si l'archivage WAL n'est pas activé ou échoue, le répertoire pg_wal (anciennement pg_xlog) sur le serveur primaire augmentera indéfiniment à mesure que de nouveaux segments WAL sont générés.

5. Slots de réplication non récupérés

Les slots de réplication garantissent que les segments WAL ne sont pas supprimés avant d'être consommés par un serveur secondaire ou un client de décodage logique spécifique. Si un slot est créé mais que le consommateur s'arrête ou se déconnecte sans que le slot ne soit supprimé, les segments WAL requis par ce slot seront conservés, même si le serveur secondaire n'est plus actif.

Gestion de l'espace disque WAL : Configuration et solutions

Gérer une activité WAL élevée nécessite une approche à plusieurs volets impliquant la surveillance, l'ajustement de la configuration et des procédures de maintenance appropriées.

1. Activer et surveiller l'archivage WAL

L'archivage WAL est le mécanisme le plus critique pour gérer l'espace disque et activer le PITR. Lorsque l'archivage est activé, les fichiers WAL complétés sont copiés vers un emplacement séparé (par exemple, un partage réseau, un bucket S3 ou un autre disque).

Configuration :

Modifiez votre fichier postgresql.conf :

wal_level = replica         # Ou logical pour la réplication logique
archive_mode = on           # Activer l'archivage
archive_command = 'cp %p /path/to/archive/%f'

# Exemple pour S3 utilisant wal-g ou un outil similaire :
# archive_command = 'wal-g wal-push %p'

%p : Espace réservé pour le chemin complet du fichier WAL à archiver.
%f : Espace réservé pour le nom de fichier du WAL.

Important : La commande archive_command doit pouvoir s'exécuter avec succès. Si elle renvoie un code de sortie non nul, PostgreSQL considérera que l'archivage a échoué, ce qui peut entraîner la non-suppression des fichiers WAL. Assurez-vous que le répertoire de destination dispose d'un espace suffisant et que l'utilisateur exécutant PostgreSQL dispose des droits d'écriture.

Surveillance de l'archivage :

Utilisez des requêtes SQL pour vérifier l'état de l'archivage :

SELECT archived_count, failed_count FROM pg_stat_archiver;

SELECT pg_current_wal_lsn() AS current_lsn,
       pg_walfile_name_offset(pg_current_wal_lsn()) AS current_wal_file,
       pg_last_wal_replay_lsn() AS replay_lsn; -- Sur le serveur secondaire

-- Vérifier les fichiers WAL qui n'ont pas encore été archivés (peut indiquer des problèmes)
SELECT pg_wal_lsn_segments(pg_current_wal_lsn() - pg_last_archived_wal_lsn()) AS segments_since_last_archive;

2. Gestion de la taille du répertoire `pg_wal`

Même avec l'archivage activé, le répertoire pg_wal sur le primaire peut grossir si les segments WAL ne sont pas supprimés après l'archivage. Cela se produit si :

Les serveurs secondaires ne suivent pas et que wal_keep_size (ou max_slot_wal_keep_size pour les slots) est trop petit pour conserver suffisamment de WAL.
Les slots de réplication conservent les fichiers WAL.

`wal_keep_size` (Pré-PostgreSQL 13)

Ce paramètre sur le serveur primaire spécifie la quantité de données WAL (en Mo) qui doit être conservée dans le répertoire pg_wal pour la réplication en flux continu. Si un serveur secondaire prend trop de retard et que la quantité de WAL nécessaire pour se remettre à niveau dépasse wal_keep_size, le serveur secondaire pourrait être incapable de se reconnecter.

# postgresql.conf sur le primaire
wal_keep_size = 1024 # Conserver 1 Go de WAL sur disque

Remarque : wal_keep_size est une approche historique. L'utilisation de slots de réplication est généralement préférée pour une réplication robuste.

`max_slot_wal_keep_size` (PostgreSQL 13+)

C'est la méthode préférée pour gérer la rétention WAL lors de l'utilisation de slots de réplication. Elle limite la quantité totale d'espace disque WAL (en Mo) qui peut être conservée par tous les slots de réplication combinés.

# postgresql.conf sur le primaire
max_slot_wal_keep_size = 2048 # Limiter les slots à conserver 2 Go de WAL

# Considérer également : wal_keep_size -- toujours pertinent pour le streaming sans slot
# wal_keep_size = 1024 # Conserver 1 Go pour le streaming sans slot

Si le WAL total requis par les slots actifs dépasse max_slot_wal_keep_size, les nouveaux fichiers WAL ne seront pas supprimés même s'ils ont été consommés par le slot, ce qui entraîne le remplissage du disque. Ce paramètre empêche l'accumulation illimitée de WAL due à des slots problématiques.

Slots de réplication

Les slots de réplication sont cruciaux pour éviter la perte de WAL et garantir une réplication fiable. Cependant, ils peuvent entraîner une accumulation de fichiers WAL s'ils ne sont pas gérés correctement.

Problème : Un slot de réplication est créé, mais le consommateur (serveur secondaire ou client logique) se déconnecte ou échoue, et le slot n'est jamais supprimé. Le serveur primaire conservera tous les fichiers WAL que le slot attend.
Solution : Surveillez régulièrement les slots de réplication et supprimez ceux qui ne sont plus utilisés.

-- Lister les slots de réplication
SELECT slot_name, plugin, slot_type, active, wal_status FROM pg_replication_slots;

-- Supprimer un slot inutilisé
SELECT pg_drop_replication_slot('slot_name_to_drop');

Avertissement : La suppression d'un slot de réplication entraînera la perte de la position de tout consommateur connecté. Assurez-vous que le consommateur n'est plus nécessaire ou qu'il a été correctement réinitialisé avant de le supprimer.

3. Ajuster `min_wal_size` et `max_wal_size`

Ces paramètres contrôlent la quantité minimale et maximale de WAL que PostgreSQL préallouera. Bien qu'ils ne provoquent pas directement une génération élevée de WAL, ils influencent la rapidité avec laquelle le répertoire pg_wal peut croître pendant les périodes de forte activité en raison de la préallocation.

min_wal_size : Garantit qu'au moins cette quantité d'espace WAL est disponible, évitant les préallocations fréquentes. Le régler trop bas peut entraîner une expansion fréquente du répertoire pg_wal.
max_wal_size : La quantité maximale de WAL que PostgreSQL conservera. Les segments plus anciens dépassant cette limite seront recyclés ou supprimés une fois qu'ils ne seront plus nécessaires pour l'archivage ou la réplication.

# postgresql.conf
min_wal_size = 1GB
max_wal_size = 4GB

Augmenter max_wal_size peut donner au système plus de marge de manœuvre pendant les pics de charge d'écriture, mais cela signifie également que plus d'espace disque sera occupé par les fichiers WAL préalloués.

4. Nettoyage régulier des fichiers WAL archivés

L'archivage WAL, bien qu'essentiel pour la récupération, peut également entraîner des problèmes d'espace disque si les fichiers archivés ne sont jamais nettoyés. Vous devez avoir une stratégie pour gérer la rétention de vos fichiers WAL archivés.

Stratégie : Mettre en œuvre un script ou utiliser un outil dédié (tel que pg_archivecleanup, pgBackRest, wal-g, barman) pour supprimer les anciens fichiers WAL de l'emplacement d'archive une fois qu'ils ne sont plus nécessaires pour le PITR ou la réplication.
**Utilisation de pg_archivecleanup :
**
Cet utilitaire peut être exécuté sur le serveur primaire pour supprimer les anciens fichiers WAL du répertoire d'archive.
bash # Sur le serveur primaire, dans le répertoire bin de PostgreSQL : pg_archivecleanup /path/to/archive/location <timelineID> <lsn_to_keep_until>
Alternativement, il peut être intégré à votre archive_command (bien que ce soit moins courant et potentiellement délicat).

Une approche plus courante consiste à planifier l'exécution périodique de pg_archivecleanup, en conservant les fichiers WAL jusqu'au point de la dernière sauvegarde réussie.

```bash

Exemple de job cron à exécuter quotidiennement, conservant les fichiers WAL jusqu'à 24 heures

Assurez-vous que cela correspond à votre stratégie de sauvegarde !

0 0 * * * pg_archivecleanup -d -v /path/to/archive/location
```

Important : Assurez-vous toujours que votre stratégie de nettoyage correspond à vos exigences de sauvegarde et de restauration à un point précis (PITR). Vous devez conserver les fichiers WAL suffisamment longtemps pour couvrir votre fenêtre de récupération souhaitée.

5. Surveillance de l'espace disque et du taux de génération WAL

Une surveillance proactive est essentielle pour éviter l'épuisement de l'espace disque.

Surveiller l'espace disque : Utilisez des outils de surveillance système (par exemple, Nagios, Prometheus, Zabbix) pour suivre l'espace libre dans votre répertoire de données et vos emplacements d'archivage.
Surveiller la génération WAL : Interrogez pg_stat_wal_receiver (sur les serveurs secondaires) et pg_stat_archiver (sur le primaire) pour comprendre l'activité WAL et le succès de l'archivage.

```sql
-- Vérifier le taux de génération WAL (approximatif)
SELECT pg_size_pretty(pg_current_wal_lsn()::bigint - pg_last_wal_write_lsn()::bigint) AS current_wal_written;

-- Vérifier l'âge des fichiers WAL
SELECT pg_walfile_name(f.path) AS wal_file, pg_wal_file_name(f.path) < pg_current_wal_lsn() AS is_old
FROM pg_ls_dir('/path/to/your/pg_wal') AS f(path)
ORDER BY f.path;
```

Étapes de dépannage en cas de disques pleins

Si votre disque est déjà plein en raison de l'activité WAL, une action immédiate est nécessaire :

Identifier la cause : Vérifiez pg_stat_archiver pour les échecs d'archivage. Examinez pg_replication_slots pour les slots inutilisés ou problématiques. Vérifiez le retard de réplication sur les serveurs secondaires.
**Libérer de l'espace (Mesures temporaires) :
- Si l'archivage est activé et fonctionne : Essayez de supprimer manuellement certains fichiers WAL archivés très anciens dont vous êtes certain qu'ils ne sont plus nécessaires pour la récupération (procédez avec une extrême prudence).
- Si l'archivage n'est pas activé ou échoue : Vous pourriez avoir besoin de déplacer temporairement les fichiers WAL complétés de pg_wal vers un autre disque si possible, ou si vous avez une sauvegarde, envisagez de réinitialiser votre base de données (c'est une mesure radicale).
**Adresser la cause profonde :
- Corriger l'archivage : Assurez-vous que archive_command est correct et que la destination dispose d'espace.
- Gérer les slots : Supprimez tous les slots de réplication inutilisés.
- Corriger la réplication : Résolvez les problèmes causant le retard du serveur secondaire.
- Augmenter l'espace disque : Ajoutez temporairement ou de manière permanente plus de stockage.
Redémarrer l'archiveur (s'il est bloqué) : Parfois, le processus d'archiveur peut se bloquer. Le redémarrage de PostgreSQL peut aider, mais assurez-vous de comprendre les implications.

Conclusion

L'activité WAL élevée est un défi courant dans les environnements PostgreSQL, découlant souvent d'opérations d'écriture intensives ou de problèmes de réplication et d'archivage. En activant et en surveillant méticuleusement l'archivage WAL, en configurant correctement les politiques de rétention avec max_slot_wal_keep_size et wal_keep_size, en gérant les slots de réplication et en mettant en œuvre une stratégie de nettoyage robuste pour les fichiers WAL archivés, vous pouvez prévenir efficacement l'épuisement de l'espace disque et maintenir une base de données PostgreSQL saine et fiable. Une surveillance proactive reste votre meilleure défense contre ces problèmes.