流复制浅析 —— 延迟备库

作者：瀚高PG实验室（Highgo PG Lab）-天蝎座

延迟备库是指可以配置备库与主库的延迟时间，这样备库始终和主库保持指定时间的延迟。

延迟备库的意义：

一般流复制环境下，如果主库不是很忙并且备库硬件资源充分，通常备库和主库的延时能在毫秒级别。如果主库上误操作删除了表数据或者表，从库上的这些数据也瞬间就被删除，即使对数据库做了备份，要恢复到删除前的状态也是有难度的，需要做PITR维护成本较高。在这种场景下，延迟备库在一定程度上缓解了这一问题。

延迟备库的部署：

在备库revocery.conf配置文件中配置 recovery_min_apply_delay.该参数默认毫秒，支持ms，s，min，h，d

流复制中的主库提交事务后，主库会将此事务的WAL日志流发送给备库，备库接收WAL日志流后进行重做，这个操作通常瞬间完成，延迟备库实际上是设置备库延迟重做WAL的时间，而备库依然及时接收主库发送的
WAL日志流，只是不是一接收到WAL后就立即重做，而是等待设置的时间再重做。

postgres=#  select now(),create_time from test_delay;
              now                         |     create_time
-------------------------------+---------------------
2021-03-18 16:26:30.821791+08 | 2021-03-18 16:24:25
(1 row)

recovery_min_apply_delay参数设置过大会使备库的pg_wal日志因保留过多的WAL日志文件而占用较大硬盘空间。

recovery_min_apply_delay对同步复制有何影响？
前面我们提到过一个同步流复制相关的参数：synchronous_commit

remote_write:
当流复制提交事务时，需等待备库接收到主库发送的WAL日志流写入备节点操作系统缓存中之后返回成功。备库宕机不会导致事务丢失，但是如果备库操作系统宕机存在事务丢失的风险。本地WAL落盘，备库WAL还在备库操作系统缓存中，只有一份持久化的WAL。
on:
设置成on表示流复制主库提交事务时，需等待备库接收主库发送的WAL日志流写入WAL文件才返回成功。本地WAL落盘，备库的WAL也已经落盘，有两份持久化的WAL。但此时备库还未完成apply。
remote_apply:
表示流复制主库提交事务时，需等待备库接收主库发送的WAL并写入WAL文件，同时备库已经完成重做后才返回成功。本地和备库的WAL都已经落盘，有两份持久化的WAL，同时备库也完成了apply。

特别注意：
当同步流复制设置recovery_min_apply_delay参数后，若synchronous_commit= remote_write，则备库服务器宕机时存在事务丢失的风险。
所以在同步流复制中，一般推荐设置为on 或者remote_apply，
当synchronous_commit设置为on时，与异步流复制一致。当synchronous_commit设置为remote_apply时，主库写操作则会被阻塞recovery_min_apply_delay参数所设置的时间。

除此以外，我们应当知晓当wal日志产生速度非常快的情况下，可能会因为磁盘的IOPS或网络带宽的限制，导致STANDBY延迟不断增大。这种情况除了更换更好的硬件外暂无其他手段。