Postgresql -Standby数据库的搭建

数据库服务器通常允许存在一个与主库同步的在线备数据库服务器，当主数据库服务器出现故障，备数据服务器就可以快速提升为主服务器并提供服务。
Postgresql 中提供读写全功能的数据成为Primary database 或 master database。

• warm stanby server ：备份数据库在主从同步数据时不能提供只读服务
• hot stanby server ：备份数据库在主从同步数据时能提供只读服务

原理

pg_xlog 目录中始终维护这一个WAL 日志文件，这个日志文件作用在于记录数据库文件的每次改变，在数据库异常后，可以通过重放最后一次checkpoint之后的日志文件能够把数据库推到一致状态。这样也提供了一种热备方案，在使用文件系统备份数据库的同时，将WAL日志也备份出来（即使备份中数据块被修改，但是可以通过WAL日志重放推到一致性），不断通过重放WAL日志可以将数据库备份推到备份结束后的任意一个时间点，即基于时间点备份（Point-in-time-Recovery）。这样我们可以将一个基础备份恢复到一台机器上，然后不断从原始数据库传输WAL日志，这样就可以实现数据库的备份，新机器上的数据库称之为Stanby数据库。

WAL 归档

所谓WAL日志归档就是吧WAL日志备份出来，在Pg中配置归档的方法就是配置参数 archive_command 参数配置值可以是一个Unix命令(如cp)
archive_command = on
archive_command = ‘cp %p /backup/pgarch/%f’
使用scp 命令可以将WAL日志文件拷贝到其他机器上，从而实现跨机器的备份。
使用如上拷贝WAL日志的方式来同步主备数据库，备库会落后主库一个WAL日志，具体落后多长时间要看主库生成一个WAL日志所需的时间。

流复制（Stream Repliaction）

Pg9.0后提供的一种新的传递WAL日志的方式。使用流复制，只要主库一产生WAL日志，就会马上传递到Standby数据库。流复制传递日志的方式有两种

• 同步方式 ：主库提交事务时一定会等到WAL日志传递到Stanby数据库才会返回，这样可以做到主库与备库完全同步，没有任何落后。
• 异步方式 ：主库事务提交不必等待日志传递到备库即可返回，但是Standby数据库通常会比主库落后几秒
  流复制不仅能传递wal日志还能传递其他数据比如数据文件。

Standby的运行原理

Pg异常之后，重启时，会重放停机前的最后一个checkpoint之后的wal日志，把数据库恢复到停机之前的状态，自动进入正常状态可以提供读写服务。通过一个基础备份启动B库，然后备库不断接收来自A库的wal日志并重放，直到A库异常，再让B库进入正常状态可读性，这样B库就称为了A库的Stanby数据库。这样可以实现A库故障时，B库可以自动接管。
使用同步方式进行wal日志传递时如果备库故障，主库是否会hang住？
Pg提供了多个备库的功能，只有当所有备库都故障时才会导致主库不能写。
9.2之后standby提供级联功能，即stanby数据库也可以连接另外一个standby数据库。

搭建Standby 数据库

分为两大步骤
一、 生成基础备份 ，可使用pg_basebackup g工具
二、将基础备份拷贝至备机上，配置recovery.conf把备库启动在Stanby模式下

异步Standby 数据库搭建

1. 修改主库 pg_hba.conf 配置，使主库允许接收流复制的连接如下
   host replication oshba 网段 md5
2. 需要改主库 postgresql.conf 配置文件， 使用流复制必须将 max_wal_senders 改为大于零的整数
   listen_addresss = “*”
   max_wal_senders = 5
   wal_level = hot_standby
3. 使用pgbasebackup 在备库上连接主库生成基础备份（如果使用-R 参数会自动生成 recovery.conf文件）
4. 修改 standby数据库上postgresql.conf 的参数,然后启动standby数据库
   host_standby = on

同步Standby数据库搭建

1. 修改主库 pg_hba.conf 配置，使主库允许接收流复制的连接如下
   host replication oshba 网段 md5
2. 需要改主库 postgresql.conf 配置文件， 使用流复制必须将 max_wal_senders 改为大于零的整数,主库上指定standby数据库的名称
   synchronous_standy_names = ‘standby1,standby2’
   max_wal_senders = 5
   wal_level = hot_standby
3. 在Stanby1上修改recovery.conf 中配置项primary_info 中增加连接参数 application_name。即standby1,然后启动数据库
4. 在Stanby2上修改recovery.conf 中配置项primary_info 中增加连接参数 application_name。即standby2,然后启动数据库
5. 在主库上启动同步复制: 修改synchronous_standy_names 不需要重启数据库，只需要重现加载配置
   pg_ctl reload -D /home/osddba/pgdata

HotStandby的限制

DML 语句（ INSERT,UPDATE,DELETE,COPY FROM,TRUNCATE）和DDL 不能在Hot Standby数据库执行。 另外SELECT FOR SHARE | UPDATE 也不能执行，因为在PG中行锁是更新数据行的，虽然不能使用行锁但是可以使用部分表锁，但是需要在BEGIN事务中使用。

查询冲突

主库上的一些操作会在Hot Standby 上产生冲突，会导致Standby上正在执行的查询被取消，这些操作如下：

• 主库上册Vacuum进程清理掉了备库上查询还需要的多版本数据
• 直接上执行 Lock 或者各种DDL 语句会在表上 产生 Exclusive锁，导致备库上查询该表时产生冲突。
• 当主库上删除一个表空间时，而备库上的查询需要存放一些工作临时文件在此表空间
• 当主库上删除了一个数据库，而备库上还有很多session还连接在这个数据库上。

当发生冲突时，可以通过如下方法处理：

• 让备库上的应用WAL日志等待一段时间，等备库上的查询结束后再应用
• 取消备库上正在执行的查询

可以通过如下参数调整应用WAL日志的等待时间：

• max_standby_archive_delay:备库从WAL归档中读取WAL时的最大延迟，默认为30秒，-1表示一直等待
• max_standby_streaming_delay ： 备库从流复制中读取WAL时的最大延迟，默认为30秒，-1表示一直等待

大多数冲突时因为主库上把备库还需要的多版本数据清理掉了，这个问题可以通过在备库上设置参数hot_standby_feedback 为true来解决，设置此参数为true后，备库会通知主库哪些多版本数据还需要，这样主库上的autovacuum就不会清理这些数据。或者把主库上的参数vacuum_defer_cleanup_age调得大一些，让其延迟清理。