PG的延迟复制及相关参数的设置影响

说明： 下文的部份内容节选自《PostgreSQL实战》

PG的延迟复制

参数： recovery_min_apply_delay

 

某些状况下，一个后备服务器会尽快恢复来自于主服务器的 WAL 记录。有一份数据的延时拷贝是有用的，它能提供机会纠正数据丢失错误。这个参数容许你将恢复延迟一段固定的时间，若是没有指定单位则以毫秒为单位。例如，若是你设置这个参数为5min，对于一个事务提交，只有当后备机上的系统时钟超过主服务器报告的提交时间至少 5分钟时，后备机才会重放该事务。

 

有可能服务器之间的复制延迟会超过这个参数的值，在这种状况下则不会增长延迟。注意延迟是根据主服务器上写 WAL 的时间戳以及后备机上的当前时间来计算。因为网络延迟或者级联复制配置致使的传输延迟可能会显著地减小实际等待时间。若是主服务器和后备机上的系统时钟不一样步，这会致使恢复比预期的更早应用记录。但这不是一个主要问题，由于这个参数有用的设置比服务器之间的典型事件误差要大得多。

 

只有在事务提交的 WAL 记录上才会发生延迟。其余记录仍是会被尽量快地重放，这不会成为问题，由于 MVCC 可见性规则确保了在对应的提交记录被应用以前它们的效果不会被看到。

 

一旦恢复中的数据库已经达到一致状态，延迟就会产生，直到后备机被提高或者触发。在那以后，后备机将会结束恢复而且再也不等待。

 

这个参数的目的是和流复制部署一块儿使用，可是，若是指定了该参数，全部的状况下都会遵照它。使用这个特性也会让hot_standby_feedback被延迟，这可能致使主服务器的膨胀，二者一块儿使用时要当心。

 

 

延迟备库的搭建很简单， 只要在 recovery.conf 里面增长个配置项便可

recovery_min_apply_delay = 1min  # 这里我测试就设置1分钟的延迟

## 默认的支持时间单位为 ms 、s、min、h、d 即 毫秒 秒 分钟 小时 天

 

注意：修改后，须要重启 standby节点才能生效。

 

 

 

而后，在主库建立表并插入一条测试数据：

postgres=# create table test_delay(id int4,create_time timestamp(0) without time zone);

postgres=# insert into test_delay (id,create_time) values (1,now());

 

而后，等一分钟左右到延迟standby节点去查看下数据是否同步过去

 

 

延迟复制场景下 recovery_min_apply_delay 参数对同步复制的影响

同步复制状况下， 一般要 synchronous_commit 配置为 on 或 remote_apply

on 表示 standby将wal接收到 --> 写入wal日志文件 --> 向客户端返回成功。

standby表示 standby将wal接收到 --> 写入wal日志文件 --> 并应用到standby --> 才会向客户端返回成功。

 

 

下面对 synchronous_commit 不一样参数下，而且设置了延迟复制的测试：

 

场景1： synchronous_commit=on  而且 recovery_min_apply_delay = 1min

注意：

synchronous_commit是设置在主库的postgresql.conf中的(支持会话级别设置,也能够修改配置文件reload后全局生效)。

recovery_min_apply_delay 是设置在standby的recovery.conf中的。

 

这种场景下， 咱们在主库上插入一条数据，主库会当即返回执行成功or失败的结果。 而后咱们到延迟复制的standby去查询，发现仍是会须要1min后才能查到这条数据。

也就是说， 延迟备库场景下， synchronous_commit 配置为on时 和 异步流复制是一致的。

 

 

 

 

场景2： synchronous_commit=remote_apply  而且 recovery_min_apply_delay = 1min

注意：

synchronous_commit是设置在主库的postgresql.conf中的(支持会话级别设置,也能够修改配置文件reload后全局生效)。

recovery_min_apply_delay 是设置在standby的recovery.conf中的。

 

这种场景下， 咱们在主库上插入一条数据，主库会hang住等待1min(等待从库完成apply操做)后，而后才能返回执行成功or失败的结果。

而后咱们到延迟复制的standby去查询，发现当即就能查到这条数据。

 

也就是说， 延迟备库场景下， synchronous_commit 配置为 remote_apply时，会形成主库上面的事务的提交的阻塞。

生产环境用到延迟从库的场景下，必定要避免设置 synchronous_commit=remote_apply (固然从性能角度考虑也不多会设置为remote_apply的)