1 介绍
流复制是pg数据库9.0后面版本新增的功能，基本原理是从服务器连接到主服务器，主服务器在WAL记录产生时就将它们以流式传送到从服务器中，而不必等到WAL日志文件被填充。
默认情况下，流复制是异步的，在这种情况下，主服务器提交一个事务与该变化在从服务器上变得可见之间存在短暂的延迟，不过这种延迟比基于文件的日志传送方式中要小得多，在从服务器硬件等负载条件允许的情况下，延迟通常低于一秒。
2 部署
2.1 服务器配置
| 服务器 | IP | 说明 |
|---|---|---|
| master（centos6.5） | 192.168.0.10 | pg主服务器 |
| standby(centos6.5) | 192.168.0.11 | pg从服务器 |
这里面需要注意以下几点：
- 主服务器只能有一台，但是从服务器可以根据并发负载情况具体设置多个；
- 从服务器为
只读服务器，无法进行更改操作； - 主从服务器操作系统需要一致，版本需要一致，不然会出现很多奇怪的问题。
2.2 主库配置
这里省略pg安装的步骤，实际中安装可以有多种方式，这里并不做详细的介绍。主库已经安装完成，并已经启动。
首先需要配置一个账号密码，从库需要用这个账号密码来同步数据。
postgres# CREATE ROLE replica login replication encrypted password 'replica'
为了保证安全，这个账号只能由从库来连接，需要修改pg_hba.conf的配置，如果有多个从库，只需要更改后面的IP即可。
host replication replica 192.168.0.11/32 md5
配置流复制，修改postgresql.conf。
wal_level = hot_standby # 这个是设置主为wal的主机
max_wal_senders = 8 #这个设置了可以最多有几个流复制连接，差不多有几个从，就设置几个
wal_keep_segments = 64 ＃ 设置流复制保留的最多的xlog数目，如果数据库的事务并发数过多，这个一定要设置稍大一些，避免wal日志没有同步完，主库旧wal日志就删除了，这会导致备库直接宕机
wal_sender_timeout = 60s ＃ 设置流复制主机发送数据的超时时间
max_connections = 100 # 这个设置要注意下，从库的max_connections必须要大于主库的
修改完以上的，就可以重启主库，让上面的配置生效。
pg_ctl restart -D /data1/pgdata/
2.3 从库配置
这里假定已经安装好了数据库，但是没有初始化，即没有生成pgdata的一系列文件，因为这些文件需要从主库中同步过来，包含一些wal日志。如果已经初始化了，直接删除pgdata里所有文件就行了。假定数据库的数据目录也在/data1/pgdata，注意该目录的权限，需要是700，用户为postgres。
同步主库的数据文件到从库，这一步输入的密码就是在主库配置中第一步创建的用户replica密码，这个过程需要复制主库所有的数据文件，完成后，可以发现从库的该目录文件和主库是一模一样的。
pg_basebackup -F p --progress -D /data1/pgdata -h 192.168.0.10 -p 5432 -U replica --password
修改recovery.conf，这个文件可以从share文件夹获取，直接复制出来。
cp /data1/pgdata/share/recovery.conf.sample /data1/pgdata/recovery.conf
修改下面几个参数:
standby_mode = on # 这个说明这台机器为从库
primary_conninfo = 'host=192.168.0.10 port=5432 user=replica password=replica' # 这个说明这台机器对应主库的信息
recovery_target_timeline = 'latest' # 这个说明这个流复制同步到最新的数据
postgresql.conf修改几个参数：
max_connections = 300 ＃ 一般查多于写的应用从库的最大连接数要比较大
hot_standby = on ＃ 说明这台机器不仅仅是用于数据归档，也用于数据查询
max_standby_streaming_delay = 30s # 数据流备份的最大延迟时间
wal_receiver_status_interval = 10s # 多久向主报告一次从的状态，当然从每次数据复制都会向主报告状态，这里只是设置最长的间隔时间
hot_standby_feedback = on # 如果有错误的数据复制，是否向主进行反馈
然后启动从库：
pg_ctl start -D /data1/pgdata/
2.4 验证
主库查看进程ps -ef|grep sender，这个sender进程就是wal发送的进程
postgres 3564 64185 0 Aug29 ? 00:00:08 postgres: wal sender process replica 192.168.0.11(50828) streaming 5/4ED4F868
从库查看进程ps -ef|grep receiver进程，这个wal的接收进程
postgres 34251 34245 0 Aug29 ? 00:09:54 postgres: wal receiver process streaming 5/4ED4F868
同步的wal日志为4ED4F868。
主库中有一个视图pg_stat_replication可以查看更为详细的信息，这里不再做介绍。
3 总结
通过上面的部署，发现主从流复制还是比较稳定的，作者在生产环境搭建了一套，跑了1年多，没有出现过故障，保障了业务的可靠性和稳定性。但是，随着业务的增长，一个从库可能满足不了并发查询，可以考虑拓展多台从库来满足需求，但是带来的一个问题就是主库sender的压力会比较大，另一个就是同步的延时问题。作者还是比较喜欢从简单的架构来实现优化，而不是堆叠机器来实现性能优化，因为任何系统变大，复杂度就更高，同时带来的就是不稳定的因素增多。
所以，简单就好。