5 commentaires
Commence par regarder pg_stat_replication sur le primaire. Ça te donnera le write_lag, flush_lag et replay_lag. Le replay_lag sur la replica est le plus important.
SELECT application_name, client_addr, state, sync_state, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;Ensuite, sur la replica, vérifie pg_stat_wal_receiver. Le champ latest_end_lsn et latest_end_time te donnera l'état de réception des WALs.
Si le replay_lag est grand mais pas le write_lag, c'est que la replica a du mal à appliquer les WALs, souvent un problème d'IO sur la replica ou des requêtes lentes.
Vérifie la bande passante réseau entre la primaire et la replica. Si c'est saturé ou si tu as de la latence, le transfert des WALs sera lent. iperf3 peut aider à diagnostiquer.
Regarde les checkpoints sur la primaire. Si tes wal_buffers sont trop petits ou que les checkpoint_timeout sont trop agressifs, ça peut créer des pics d'écriture qui submergent la replica.
Ok c'était un problème d'IO sur la replica. Le disque était un peu saturé par un autre process de backup qui tournait en même temps que la charge importante. J'ai décalé le backup et ça va mieux. Merci pour les commandes !
Laisser une réponse
Vous devez être connecté pour poster un message !
Ma réplication PostgreSQL est en
lag. La replica est toujours quelques secondes derrière la primaire. Comment je peux investiguer ça rapidement pour trouver la cause ?