9.4 版本之前，在流复制环境中，默认情况下备节点会实时地和主节点保留同步， 9.4 版本 在 recovery.conf 文件中新增 recovery_min_apply_delay 参数，支持备库延迟复制。

延迟复制的意义

延迟复制是有意义的，比如在某些情况下由于某种原因 误删( drop ) 一张表，在 9.4 版本之前的流复制环境，那么备节点几乎实时地会和主节点同步，如果没有备份的话，这张表就找不回了，有了延迟复制，这张表在备节点上还能保留一段时间，从而给出了较大的恢复时间。

下面通过实验验证，流复制环境搭建略。

配置延迟复制

2.1 设置备节点 recovery.conf 以下参数

1

recovery_min_apply_delay =  1min

备注：此参数默认单位为毫秒，这里设置成 1分钟，便于实验，支持的的时间单位如下：

• ms (obviously)
• s (seconds)
• min (minutes)
• h (hours)
• d (days)

2.2 重启备节点

1
2
3
4

[pg94@db2 pg_root]$ pg_ctl -m fast restart -D $PGDATA
waiting for server to shut down.... done
server stopped
server starting

备注：recovery_min_apply_delay 参数调整后，需重启数据库才生效。

2.3 主库插入数据

1
2
3
4
5
6
7
8
9
10
11

postgres=# create table test_ha(id int4 primary key,create_time timestamp(6) without time zone default clock_timestamp());
CREATE TABLE
  
postgres=# insert into test_ha(id) values (1);
INSERT 0 1
  
postgres=# select * from test_ha;
id |    create_time    
----+----------------------------
 1 | 2014-05-26 11:34:54.294264
(1 row)

备注：主库创建一张表，并插入一条数据。

2.4 备库验证

1
2
3
4
5
6
7
8
9
10

postgres=# select *,now() from test_ha order by create_time desc limit 1;
id | create_time | now
----+-------------+-----
(0 rows)
  
postgres=# select *,now() from test_ha order by create_time desc limit 1;
id |    create_time     |       now       
----+----------------------------+-------------------------------
 1 | 2014-05-26 11:34:54.294264 | 2014-05-26 11:35:58.386896-07
(1 row)

备注：之后在备库上简单的重复执行以上查询，根据以上结果，大概在 1 分钟后，备节点才有了这条数据。

延迟复制注意事项

1. Synchronous replication 模式的复制不受 recovery_min_apply_delay 参数的影响。
2. hot_standby_feedback 参数会受 recovery_min_apply_delay 参数的影响，并给主库带来膨胀。
3. 设置此参数会带来 pg_xlog 目录的增长量，因为 WAL 要保留更长的时间。
4. recovery_min_apply_delay 参数的设置各有利弊，需根据实际情况进行选择。
5. 由于 recovery_min_apply_delay 参数值为 32-bit integer, 最大值为 2147483647 ( 24 天 20 小时左右 )。

参考

• recovery_min_apply_delay (integer)
• Postgres 9.4 feature highlight: delayed standbys
• WAITING FOR 9.4 – ALLOW TIME DELAYED STANDBYS AND RECOVERY