[原创]PostgreSQL Plus Advince Server在 HA环境中一对多的Stream Replication配置（二）

三、配置主机与备机的ssh无密码登录
1、主机s1到备机s3的无密码登录
a、创建ssh目录
[root@s1 ~]# mkdir /opt/PostgresPlus/9.2AS/.ssh
b、修改ssh目录的所有者为enterprisedb
[root@s1 ~]# chown enterprisedb.enterprisedb /opt/PostgresPlus/9.2AS/.ssh/
c、切换用户为enterprisedb
[root@s1 9.2AS]# su enterprisedb
d、用enterprisedb用户来生成密钥对
bash-4.1$ ssh-keygen -t rsa -C "enterprisedb key"
-C参数之后的字符串为密钥对的备注，键入命令之后，如果已经生成过密钥对，则会提示是否重写密钥对；之后会要求输入密钥对的密码，我这里留空。
看到红色框中出现的图形，表明密钥对已经生成成功。用ll命令看看ssh目录中生成的密钥对文件：
id_rsa为私钥，id_rsa.pub为公钥。
e、接着将公钥文件copy到备机s3，建立client端可用公钥：
方法一：使用scp命令
[root@s1 /]# su enterprisedb
bash-4.1$ scp ~/.ssh/id_rsa.pub root@192.168.1.223:.ssh/authorized_keys
 
方法二：推荐使用ssh-copy-id命令
bash-4.1$ ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.223
 
到这里，使用s1的enterprisedb用户已经可以从s1无密码登录s3了：
[root@s1 ~]# su enterprisedb
bash-4.1$ ssh root@192.168.1.223
Last login: Mon Jul 15 03:07:49 2013 from 192.168.1.221
 
2、备机s3到主机s1的无密码登录
备机s3到s1的无密码登录重复1中a-e的步骤即可。
在s3中也可以无密码登录到s1了。
这一步中遇到的问题
这期间遇到一个小问题，在将备机s3的公钥copy到s1时，有错误提示为：

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
73:d9:ed:e5:0e:4c:df:de:b4:a3:c1:d3:3c:53:67:2f.
Please contact your system administrator.
出现这个问题的原因，可能是我之前在s3上做过一次与其他IP地址与s1相同的机器上的stream replication。
我的解决方法是将/opt/PostgresPlus/9.2AS/.ssh/known_hosts文件删除，删除后就正常了。
[root@s3 ~]# mv /opt/PostgresPlus/9.2AS/.ssh/known_hosts /opt/PostgresPlus/9.2AS/.ssh/known_hosts_backup

四、配置EDB的Stream Replication
1、准备工作
在主机s1和备机s3上分别创建目录ppas_fullbackup和ppas_archive
s1：
[root@s1 ~]# mkdir /opt/ppas_fullbackup
[root@s1 ~]# mkdir /opt/ppas_archive
[root@s1 ~]# chown enterprisedb.enterprisedb /opt/ppas_fullbackup/
[root@s1 ~]# chown enterprisedb.enterprisedb /opt/ppas_archive/
s3：
[root@s3 ~]# mkdir /opt/ppas_fullbackup
[root@s3 ~]# mkdir /opt/ppas_archive
[root@s3 ~]# chown enterprisedb.enterprisedb /opt/ppas_fullbackup/
[root@s3 ~]# chown enterprisedb.enterprisedb /opt/ppas_archive/
2、主库配置文件postgresql.conf修改
[root@s1 ~]# vim /opt/PostgresPlus/9.2AS/data/postgresql.conf
wal_level = hot_standby
archive_mode = on
archive_command = 'cp -i %p /opt/ppas_archive/%f < /dev/null'
有几台standby就设max_wal_senders为多少，目前先做一台standby，所以设为1
max_wal_senders = 1
hot_standby = on
log_statement = 'all'
3、主库配置文件pg_hba.conf修改
[root@s1 ~]# vim /opt/PostgresPlus/9.2AS/data/pg_hba.conf
在pg_hba.conf文件中加入下面的内容：
#add by zws for stream replication 2013.07.15
host    all    all    192.168.1.221/32        trust
host    all    all    192.168.1.223/32        trust

host    replication  enterprisedb  192.168.1.221/32     trust
host    replication  enterprisedb  192.168.1.223/32     trust
4、重启主库
[root@s1 ~]# /etc/init.d/ppas-9.2 restart
5、对主库做一次全备
[root@s1 ~]# pg_basebackup -D /opt/ppas_fullbackup/$(date +"%Y%m%d") -Ft -x -z -Z 3 -v -h 192.168.1.221 -p 5444 -U enterprisedb
 
[root@s1 /]# ls /opt/ppas_fullbackup/20130715/
base.tar.gz为全备生成的文件。
6、恢复备库
停止standby数据库，删除备库中的data目录或改名，把主库中全备的数据文件恢复到备库。
a、在备机s3中重命名ppas的data，模拟data目录损坏
[root@s3 ~]# mv /opt/PostgresPlus/9.2AS/data /opt/PostgresPlus/9.2AS/data.bak
[root@s3 ~]# mkdir /opt/PostgresPlus/9.2AS/data
[root@s3 ~]# chown enterprisedb.enterprisedb /opt/PostgresPlus/9.2AS/data
[root@s3 ~]# chmod 0700 /opt/PostgresPlus/9.2AS/data
b、把主库中全备的数据文件恢复到备库
[root@s3 ~]# scp root@192.168.1.221:/opt/ppas_fullbackup/20130715/base.tar.gz /opt/ppas_fullbackup/
c、在备机的data目录中，添加recovery.conf文件
[root@s3 ~]# cp /opt/PostgresPlus/9.2AS/share/recovery.conf.sample /opt/PostgresPlus/9.2AS/data/recovery.conf
修改recovery.conf文件的配置参数：
[root@s3 ~]# vim /opt/PostgresPlus/9.2AS/data/recovery.conf
standby_mode = 'on'
primary_conninfo = 'host=192.168.1.221 port=5444 user=enterprisedb application_name=hot_standby1'
restore_command = 'scp -Cp root@192.168.1.221:/opt/ppas_archive/%f "%p"'  
d、修改主库的配置文件postgresql.conf中的synchronous_standby_names参数：
synchronous_standby_names = 'hot_standby1'
该参数与备机的恢复文件中的primary_conninfo参数中的属性application_name是一致的，这时可以再次检查步骤c中的参数值。
e、在主机中执行reload命令，重新加载配置文件
[root@s1 /]# /etc/init.d/ppas-9.2 reload
f、启动s3上的备库，可以看到备库中的data目录已经完整恢复了。
[root@s3 ~]# /etc/init.d/ppas-9.2 start
到这里完成了一对一的Stream Replication。以下做了一个简单的操作，来验证Stream Replication是否成功：首先在主库edb库的dept表插入一行数据，随后在备库中进行查询，可以看到备库中已经同步到了刚才插入的数据。
s1：
[root@s1 pg_log]# edb-psql -U enterprisedb -c "INSERT INTO dept VALUES(60,'KFC','SHANGHAI');"
 
s3：
[root@s3 data]# psql -U enterprisedb -c "SELECT * FROM dept;"