Monitorar o lag de recebimento e de replay de WAL no standby (pg_stat_wal_receiver)
PostgreSQLReplicaçãoComando
-- Run on the standby:
SELECT pg_is_in_recovery() AS in_recovery,
pg_last_wal_receive_lsn() AS receive_lsn,
pg_last_wal_replay_lsn() AS replay_lsn,
pg_size_pretty(pg_wal_lsn_diff(pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn())) AS replay_backlog,
now() - pg_last_xact_replay_timestamp() AS last_replay_age,
pg_get_wal_replay_pause_state() AS pause_state;
SELECT pid, status, sender_host, sender_port, slot_name, received_tli, flushed_lsn, latest_end_lsn, now() - last_msg_receipt_time AS since_last_msg FROM pg_stat_wal_receiver;O que faz
Mostra quanto WAL o standby recebeu e quanto aplicou (acúmulo de replay), a idade da última transação reaplicada, se o replay está pausado e o estado da conexão do walreceiver (qual primário, slot, timeline, horário da última mensagem).
Quando usar
Para diagnosticar lag quando o primário não está acessível ou em standbys em cascata; em um alerta de 'standby atrasado', para separar um problema de rede (recebimento) de um problema de replay (I/O, conflito).
Atenção
Se pg_stat_wal_receiver não retornar linhas, o standby não está em streaming (alimentado pelo archive ou desconectado). last_replay_age cresce mesmo quando o primário não tem gravações; interprete-o junto com a diferença entre receive_lsn/replay_lsn. Se o acúmulo de replay crescer enquanto o recebimento avança, o standby tem consultas longas (max_standby_streaming_delay) ou um gargalo de I/O.