1、 延迟备库
延迟备库是指可以配置备库和主库的延迟时间，这样备库始终和主库保持指定时间的延迟，例如设置备库和主库之间的延迟时间为1小时 ，理论上备库和主库的延时始终保持在一小时左右；
1.1 延迟备库的意义
PostgreSQL流复制环境下，如果主库不是很忙并且备库硬件资源充分，通常备库和主库的延时能在毫秒级别。如果主库上由于误操作删除了表数据或删除表时，从库上的这些数据也瞬间被删除了，这时，即使对数据库做了备份，要恢复到删除前的状态也是有难度的，比如，如果使用pg_ dump 做了逻辑备份，通常是按天、按周、按月进行逻辑备份等，也只能恢复到最近逻辑备份时刻的数据，除非是做了基准备份并且开了归档，这时可以利用全量备份和归档恢复到删除前的状态，从而找回被删除的数据，当然这种方法维护成本较高。在这一场景下，延迟的备库在一定程度上缓解了这一问题，因为在设置的延迟时间范围内，备库上的数据还没被删除，可以在备库上找回这些数据，这节将详细介绍延迟备库的配置和使用，当然，如果超过了已设置的主备延迟时间才发现主库上的数据被删除了，这些数据在备库也找不回来了。
1.2 延迟备库部署
只需要配置recovery_min_apply_delay参数，此参数位于postgresql.auto.conf文件
此参数单位默认为毫秒，目前支持的时间单位如下：
ms（毫秒，默认单位）
s（秒）
min（分钟）
h（小时）
d（天）
大家知道流复制主库提交事务后，主库会将此事务的WAL日志流发送给备库，备库接收WAL日志流后进行重做，这个操作通常瞬间完成，延迟的备库实际上是设置备库延迟重做WAL的时间，而备库依然及时接收主库发送的WAL日志流，只是不是一接收到WAL后就立即重做，而是等待设置的时间再重做，假如设置此参数为一分钟，流复制备库接收到主库发送WAL日志流后需等待一分钟才重做。
注意：recovery_ min_ apply_ delay 参数设置值过大会使备库的pg_ wal日志因保留过多的WAL日志文件而占用较大硬盘空间，因此设置此参数时需要考虑pg _wal目录可用空间大小，当然，如果设置得太小，留给恢复的时间窗口太短可能起不到数据恢复的用途。
1.3 recovery_min_apply_delay 参数对同步复制的影响
同步复制 synchronous_commit 参数需配置成 on 或 remote_apply，on 选项意思是主库上提交的事务会等待备库接收WAL日志流并写入WAL日志文件后在向客户端返回成功，remote_apply 更近一步，主库上提交事务后会等待备库接收WAL日志流并写入WAL日志文件同时应用完成WAL日志流后在向客户端返回成功；
对于延迟备库场景，synchronous_ commit 配置为on时和异步流复制一致，synchronous. commit配置为 remote_ apply 时，主库上所有的写操作将被阻塞一定时间，被阻塞的时间正好是同步备库recovery_ min_ apply_ delay参数配置值，因此synchronous_commit参数配置为remote_apply的同步流复制环境应避免使用延迟备库。
recovery_min_apply_delay
主：
备：
