PostgreSQL的一次恢复记录

概述有一段时间没有做PostgreSQL的一线恢复了，一直都挺稳定，直到上周省公司产品部打电话，告知数据库不可用了。其实上上周已经协助省公司做过一次主备切换，因为疑似磁盘故障还是文件系统故障导致某几张大表不可读，但是上周又告知备机出故障了，就去现场做了一次支撑。仅记录一下，以备查看。   一、环境 OS：CentOS 6.x DB：PostgreSQL 9.1 DBSize：600G 二、现状与分析

有一段时间没有做Postgresql的一线恢复了，一直都挺稳定，直到上周省公司产品部打电话，告知数据库不可用了。其实上上周已经协助省公司做过一次主备切换，因为疑似磁盘故障还是文件系统故障导致某几张大表不可读，但是上周又告知备机出故障了，就去现场做了一次支撑。仅记录一下，以备查看。

一、环境

OS：CentOS 6.x
DB：Postgresql 9.1
DBSize：600G

二、现状与分析
维护人员告诉我，备机进不去了，

--登陆报错psql: FATAL: the database system is starting up查看进程，也不完整，只有两个postgres进程，查看日志，里面有很多报错信息，如下：2017-01-1913:25:29.430 CST,27618,59d111c8.1c5a,2,2017-01-1913:25:28 CST,FATAL,XX000,"Could not receive data from WAL stream: FATAL: requested WAL segment 0000000600002B0000000000 has already been removed

分析：
日志其实提示很明显，就是备库所需要的主机上的wal日志被循环覆盖了，看样子是之前维护人员尝试从主机同步数据到备机，然后启动报的错，这里有两点需要注意：

1.主机上的wal日志是类似于Oracle的Redo file或者MysqL的ib_data组，是用来记录数据库事务的文件，是循环记录的；
2.备机恢复时需要读取wal日志，如果不完整或者丢失就会造成恢复中断，就是本例登数据库时一直显示启动中的状态。

这个库比较大，600多G的库传输和恢复需要一个多小时，这么长时间容易导致wal日志被覆盖。解决办法通常有两个，一个是增加wal存盘的数量，但是不好控制，另一个是做一个归档，将新生成的wal日志备份出来，这次采用的是第二个办法。

三、处理

主机上打开归档

archive_mode = on             --改变这个参数需要重启，建议初始化数据库就打开archive_command = 'cp %p /archive/%f'   --修改这个参数只需要reload--重载配置生效[postgres@bigdata1~]pg_ctl -D $PGDATA reload

这个时候就可以看到/archive下面会生成很多新的wal日志了

备机搭建：
使用pg_basebackup方式，参考http://www.jb51.cc/article/p-zfxbryhb-bog.html，略
库比较大，用pg_basebackup备份一开始会有点卡，然后就是一个多小时的传输等待了，拷贝结束，启动还是照样会报错，这个时候需要改一下备机的参数

--备机创建接收的归档文件夹[postgres@bigdata2~]$mkdir /archive_stand--将主机上的archive文件拷贝到备机上来[postgres@bigdata1~]scp /archive/* postgres@192.168.2.199:/archive_stand--修改postgresql.conf参数restore_command = 'cp /archive_stand/%f %p'--重命名recovery.done为recovery.conf，修改里面的primary连接信息，主要是IP改为主机，此处略--再重新启动，可以发现缺失的wal日志被apply了，恢复成功有success字样日志输出2017-01-1915:36:08.592 CST,4108,81e20156.fa8,5,2017-01-1915:36:09CST,1/0,LOG,00000,"restored log file ""0000000600000002F00000021"" from archive",""

四、后续其他 1.关闭主备机上的archive存档，不然会撑爆磁盘 2.验证主备数据同步，可以通过建一张新表或者插一条测试数据在备机上是否同步来验证 3.数据库的版本有点低，存在一些BUG，pg_basebackup版本同样也低，不像高版本有限流的一些参数(max_rate)，开启同步会消耗大量的IO，如有可能，最好做下升级

总结

以上是内存溢出为你收集整理的PostgreSQL的一次恢复记录全部内容，希望文章能够帮你解决PostgreSQL的一次恢复记录所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。