连接PostgreSQL时看到the database system is in recovery mode，说明当前实例尚不能按预期接受这类连接。它可能仍在启动后的WAL恢复，也可能是按设计运行的备库。
先分清实例角色和恢复进度，再决定是否需要操作。直接删除信号文件或强行提升备库可能破坏复制拓扑。
先看启动日志与服务状态
检查systemctl status postgresql以及对应实例日志，记录启动时间、WAL重放、是否达到一致性状态和后续错误。容器部署应读取实际数据库容器日志。
短暂的启动恢复与长时间卡住不是同一故障。恢复持续时间与WAL量、磁盘性能及前次关机状态相关。
确认是不是预期中的备库
官方热备文档说明，备库在归档恢复或standby模式下可在达到一致性状态后提供只读查询；hot_standby需要启用。能连接时执行SELECT pg_is_in_recovery();识别当前角色。
结果为true说明仍处于恢复流程，不代表实例异常。应用写入应指向主库。
检查连接入口和路由
核对应用连接串、代理、负载均衡和DNS是否把请求送到了备库。若只读查询也无法连接，检查热备配置及日志中是否显示还未达到一致性状态。
不要靠反复重启备库解决错误的主备路由。先修正应用的写入入口。
持续无法恢复时处理什么
确认磁盘空间、WAL来源和归档是否可用，检查是否存在复制连接中断或需要的WAL缺失。保留原日志与备份信息，按当前PostgreSQL版本的恢复手册处理。
不要手工删除pg_wal或随意移除standby.signal。这可能导致恢复失败或意外改变实例角色。
在隔离环境验证切换
需要调整主备路由或恢复演练时，可在萤光云或LightNode的独立实例先走完整流程。验收应包括主库可写、备库只读以及复制延迟处于可接受范围。
FAQ
问：pg_is_in_recovery()为true就要执行提升吗？答：不需要。备库返回true是正常现象；只有明确的故障切换方案才应考虑提升。
温馨提示
温馨提示：恢复期间应保留可验证的备份和WAL链；不要在没有拓扑图与回退方案时修改主备角色。
