有一段时间没有做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，如有可能，最好做下升级
