postgresql数据库主从恢复的实现

一、验证数据库

动手操作前，第一步永远是验证环境。这能帮你摸清数据库的“底”，确保后续步骤踩在实地上。咱们按顺序来。

1、查看剩余空间

数据库运行和备份都离不开磁盘空间。先运行下面这条命令，看看各挂载点的使用情况，心里有个数。

df -h

2、查看数据库进程

数据库服务是否在线，是基本检查项。用这个命令快速确认一下PostgreSQL主进程的状态。

pg_ctl status

3、查看流复制状态

对于主从架构，WAL发送进程是同步的关键。执行这行命令，可以检查相关的WAL进程是否存在且运行正常。

ps -ef | grep wal

4、查看主从节点集群状态

这是获取全局视图的关键一步。通过repmgr工具，可以清晰地看到集群中所有节点的角色、状态和连接关系。

su - postgresql -c "repmgr -f /repmgr/repmgr.conf cluster show" 

5、查看连接状态（主库执行）

了解当前有哪些客户端连接到了数据库，以及连接数量分布，有助于判断业务负载和潜在风险。这个查询在主库执行效果最佳。

su - postgres -c "psql -c 'select client_addr,count(*) from pg_stat_activity group by 1 order by 2 desc;'"

二、备份数据库

在开始任何恢复性操作之前，做好完整的环境快照是必不可少的“安全绳”。这一步收集的系统信息，万一遇到问题，将是回溯和诊断的宝贵依据。

将以下命令序列保存为脚本或逐条执行，它会把关键的系统配置、存储状态和资源使用情况归档到指定日志文件中。

ll /dev/sd* > /tmp/sd_info_2025XXXX.log
df -Th >>/tmp/df_info.log
mount >>/tmp/mount_info.log
free -g >>/tmp/free_info.log
multipath -ll >> /tmp/multipath_info.log
uptime>>/tmp_uptime_info.log
vgs>> /tmp/vgs_info.log
pvs>> /tmp/pvs_info.log
lvs>>> /tmp/lvs_info.log

三、恢复操作

当确认需要重建从库时，下面这套流程经过了大量实践检验。请严格按照顺序执行，并密切观察每一步的输出。

1、停止从库数据库

首先，安全地停止待恢复从库的数据库服务，并确认其已完全停止。

su - postgres
pg_ctl stop
pg_ctl status

2、备份从库数据目录

这是一个关键的安全操作。即使数据目录可能已损坏，重命名备份也能防止误操作导致彻底丢失，为回滚留有余地。

su - postgres
mv /pg/data  /pg/data_2025XXXX

3、克隆数据库(从库执行)

这是核心步骤，即从主库拉取一份完整的数据副本。使用nohup和输出重定向是为了让命令在后台执行，并将日志保存下来便于排查。注意替换 $hostname 为主库的实际主机名或IP。

su - postgres
nohup repmgr -h $hostname -d repmgr -c --replication-user=postgres -D /pg/data standby clone --upstream-node-id=1 > /tmp/repmgr.log 2> /tmp/repmgr.err &

4、启动数据库

克隆完成后，启动新的数据库实例，并立即检查其运行状态。

pg_ctl start
pg_ctl status

5、注册从节点（从库执行）

启动成功后，需要将此节点重新注册到复制管理集群中，使其被主库和其他节点感知。-F 参数通常用于强制注册。

su - postgres
repmgr -f /repmgr/repmgr.conf standby register -F
repmgr -f /repmgr/repmgr.conf standby cluster show

6、查看数据库日志

最后，也是最重要的一步：仔细检查数据库日志。这里是观察复制是否真正建立、有无报错的“第一现场”。关注日志中的“streaming replication”等相关信息。

tail -1000f /pg/data/pg_log/postgresql-2025-XX-XX.csv