PostgreSQL提示the database system is starting up，恢复进度定位方法

数据库重启后客户端提示 the database system is starting up，意味着连接已到达PostgreSQL，但服务器当前还不能接受普通会话。断电后的崩溃恢复、从备份启动、备库回放WAL，都可能出现一段等待期。单凭这行提示，不能判断数据已经损坏。

最重要的动作是先保护现有数据，再看日志能否持续推进；反复强制重启或删除WAL文件会使排障更难。

确认连接目标和服务状态

用实际业务连接的地址与端口检查，不要只在服务器本机测默认Socket：

pg_isready -h 127.0.0.1 -p 5432
systemctl status postgresql --no-pager

pg_isready 会区分接受连接、拒绝连接和无响应；服务单元名称因发行版及实例版本而异。拒绝连接说明服务可能正启动，完全无响应则还需检查监听地址、端口和进程。 多实例服务器要先确认正在观察的是业务使用的那个集群。

先查看对应实例的最近日志，留意恢复起点、WAL回放进度、就绪提示及重复出现的FATAL或PANIC：

journalctl -u postgresql -n 150 --no-pager

有些发行版把真实实例放在带版本号的单元下，或把日志写到PostgreSQL自己的日志目录。应根据安装方式查看该实例日志，不要凭通用 postgresql.service 的状态就断言数据库已就绪。若日志持续推进，可以给恢复留出时间；若总停在相同的缺失文件或I/O错误，应先处理根因。

主库非正常关机后需要回放WAL以恢复一致性；备库则可能长期处在恢复模式，但配置了热备查询后仍能接受只读连接。恢复模式本身并不等于故障。 PostgreSQL文档提醒，崩溃恢复启动时间可能超过服务管理器的默认等待时长。

连接已恢复后，可在正确的实例上查询：

SELECT pg_is_in_recovery();

结果为 true 表示当前实例仍在恢复模式，常见于备库；若目标本应是可写主库，再核对启动角色和恢复配置，不要直接把备库强行提升。

恢复需要能读取WAL并写入必要的数据。核对数据盘空间、inode和挂载是否正常：

df -h
df -i
findmnt

若日志指出磁盘已满或只读挂载，应先解决存储问题。不要为了腾空间手工删除 pg_wal 中的文件，也不要删除 postmaster.pid 来反复启动。 这些操作可能破坏可恢复的数据，先保留备份与日志。

记录本次重启时间、PostgreSQL版本、实例目录、服务单元以及日志中最后一条持续更新的恢复消息；同时确认是否刚做过基于时间点的恢复或从备份重建。按时间顺序比对日志，比只截取最后一行连接报错更有价值。

需要在隔离环境复现恢复流程时，可使用 萤光云 或 LightNode 的测试服务器。只使用脱敏备份，生产数据不得随意拷入临时实例。

日志持续出现回放进度，且磁盘和服务状态正常，可以继续观察。日志明确报缺失WAL、校验失败、I/O故障或服务被systemd循环终止，就应停止无意义的重启，先固定备份并按具体错误处理。

不要把持续等待当成所有场景的解决方法，也不要以 pg_resetwal 作为常规启动手段。 数据一致性优先于暂时消除报错。

再次针对业务实际地址运行 pg_isready，用应用账户完成一次受限查询，并查看服务日志是否出现就绪消息。应确认主库的可写角色与备库只读角色符合架构预期。

验收标准是应用稳定建立连接、日志不再重复恢复失败、所连实例的角色正确。 一次 pg_isready 成功不代表所有应用连接串都已切回正确节点。

看到这个提示要立刻重启数据库吗？ 不要。先看恢复日志是否有进展，重复重启会打断当前恢复，也可能掩盖真正错误。

备库显示仍在恢复，为什么能查询？ 开启热备查询的备库可以在持续回放WAL时提供只读连接，恢复模式和可用性并非同一判断。

先保留日志和现有数据，再区分正常等待与明确失败。 当日志出现存储故障或缺失WAL时，应优先保护备份并按实际报错处理。