ApsaraDB RDS:Résoudre l'accumulation des journaux WAL dans PostgreSQL

Emplacements de réplication inactifs ou LSN non signalés

Un emplacement de réplication est un outil essentiel dans PostgreSQL pour mettre en œuvre la haute disponibilité et la reprise après sinistre. Il indique à PostgreSQL de ne pas supprimer les journaux WAL tant que le consommateur ne les a pas traités. Si un emplacement devient inactif, par exemple parce que le consommateur a cessé de signaler son numéro de séquence de journalisation (LSN), les journaux WAL associés à cet emplacement s'accumulent indéfiniment.

Étape 1 : Identifiez les emplacements qui bloquent la suppression des journaux WAL.

Exécutez la requête suivante sur la vue système pg_replication_slots pour vérifier la quantité de journaux WAL retenue par chaque emplacement :

SELECT slot_name, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_insert_lsn(), restart_lsn)) AS delay_size
FROM pg_replication_slots;

Si la valeur delay_size d'un emplacement est élevée ou correspond à l'accumulation totale des journaux WAL que vous observez, il est probable que cet emplacement bloque la suppression.

Étape 2 : Supprimez l'emplacement inactif.

Évaluez si l'emplacement reste nécessaire selon vos besoins métier, puis supprimez-le le cas échéant :

SELECT pg_drop_replication_slot('<slot_name>');

Étape 3 : Confirmez la suppression.

Réexécutez la requête d'identification de l'étape 1 pour vérifier que l'emplacement a bien été supprimé.

Pour plus d'informations sur la gestion des emplacements de réplication, consultez la section Utiliser la fonctionnalité de gestion des journaux WAL.

Paramètres incorrects

Si les paramètres wal_keep_segments (PostgreSQL 12 et versions antérieures), wal_keep_size ou max_wal_size sont définis trop haut, PostgreSQL conserve beaucoup plus de journaux WAL que nécessaire. Vérifiez les valeurs actuelles et réduisez-les afin qu'elles correspondent à vos besoins réels en matière de réplication et de récupération.

Tempête VACUUM et volume d'écriture élevé

Une tempête VACUUM, caractérisée par l'exécution simultanée de nombreuses opérations VACUUM automatiques ou manuelles, génère un volume important de journaux WAL sur une courte période. Cela peut entraîner une augmentation soudaine de la charge d'E/S et retarder le nettoyage des journaux WAL. Pour réduire l'impact, ajustez les paramètres VACUUM et échelonnez leur exécution afin de répartir la charge dans le temps.

Un débit d'écriture élevé produit un effet similaire. Planifiez les écritures groupées pendant les heures creuses lorsque cela est possible.

Latence de réplication

Les journaux WAL s'accumulent sur une instance en lecture seule lorsque la relecture prend du retard. Deux causes fréquentes expliquent ce phénomène :

• Transactions longues bloquant la relecture. Une transaction de longue durée sur l'instance en lecture seule peut entrer en conflit avec la relecture des journaux WAL. Examinez les paramètres hot_standby_feedback et max_standby_streaming_delay. Par exemple, si hot_standby_feedback est défini sur off et que max_standby_streaming_delay possède une valeur élevée, les requêtes de longue durée exécutées sur l'instance en lecture seule peuvent considérablement retarder la relecture.

• Spécifications insuffisantes de l'instance en lecture seule. Si l'instance en lecture seule dispose de capacités de calcul ou de stockage inférieures à celles de la base de données principale, elle peut ne pas suivre le flux de réplication. Les journaux WAL non rejoués ne peuvent pas être supprimés. Évaluez et sélectionnez des spécifications adaptées pour la base de données en lecture seule en fonction de vos besoins métier.