sylph mini1. PostgreSQL 恢复监控的核心价值
作为一名长期与PostgreSQL打交道的DBA，我深知数据库恢复过程就像一场与时间的赛跑。当主库宕机，每一秒的恢复延迟都意味着业务损失。这个SQL查询工具就是我的"恢复仪表盘"，它能实时告诉我：恢复进行到哪一步了？有没有卡住？还需要多久？
传统监控往往只能告诉你"数据库是否在线"，而这个查询揭示了更深层的状态信息。比如通过比较pg_last_wal_receive_lsn()和pg_last_wal_replay_lsn()，我能立即判断WAL日志的接收和应用是否存在延迟。上周我们一个TB级数据库恢复时，正是这个差值让我发现磁盘IO成为瓶颈，及时调整了max_worker_processes参数。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 查询代码深度解析
2.1 基础状态检测函数
sql复制SELECT
pg_is_in_backup(), -- 是否正在备份中
pg_is_in_recovery(), -- 是否处于恢复模式
pg_backup_start_time() -- 备份开始时间(若在备份中)
这三个函数构成了恢复监控的基础：
pg_is_in_backup()返回布尔值，特别适用于验证pg_start_backup()发起的物理备份是否仍在进行pg_is_in_recovery()是判断备库状态的关键，我常在自动化脚本中用这个函数实现故障转移决策pg_backup_start_time()的时间精度高达微秒级，对于追踪长时间备份非常有用
2.2 恢复过程详细指标
sql复制-- 以下函数仅在恢复模式下返回有效值
(CASE WHEN pg_is_in_recovery() THEN pg_is_wal_replay_paused() END) AS replay_paused,
(CASE WHEN pg_is_in_recovery() THEN pg_last_wal_receive_lsn() END) AS last_receive_lsn,
(CASE WHEN pg_is_in_recovery() THEN pg_last_wal_replay_lsn() END) AS last_repl