PostgreSQL-搭建延迟备库

1.延迟备库简介 

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

例如设置备库和主库的延迟时间为 1 小时，理论上备库和主库的延时始终保持在一个小时

左右。

 延迟备库的意义：

如果主库上由于误操作删除了表数据时，从库上的这些数据也瞬间被删除，这时，即使对

数据库做了备份，要恢复到删除前的状态也是有难度的。在这一场景下，延迟的备库在一

定程度上缓解了这一问题，因为在设置的延迟时间范围内，备库上的数据还没被删除，可

以在备库上找回这些数据。如果超过了已设置的主备延迟时间，那备库上的数据也删除了

 延迟备库部署

recovery_min_apply_delay = '60s'

 延迟备库实际上是设置备库延迟重放 wal 的时间，而备库依然及时接受主库发送的 wal 日

志流，只是不是接受到 wal 后就立即重做，而是等待设置的时间再重做。

注意：recovery_min_apply_delay 设置的过大会使备库的 pg_wal 目录保留过多的 wal

日志文件，占用大量的硬盘空间，因此设置时需要考虑 pg_wal 目录的可用空间大小。如

果设置的太小，留给恢复的时间窗口太短，可能起不到数据恢复的用途。

• 有两个参数是控制 wal 应用的： 

SELECT pg_wal_replay_pause(); --暂停应用 wal 
SELECT pg_wal_replay_resume(); --重新应用 wal

 2.测试延迟

• 主库写入数据

postgres=# create table t1 (id int); 
CREATE TABLE 
postgres=# insert into t1 values(1); 
INSERT 0 1

• 备库查询数据

postgres=# select * from t1; 
ERROR: relation "t1" does not exist on 
LINE 1: select * from t1; 
 ^ 
postgres=# select * from t1; 
 id 
---- 
 1 
(1 row)


#60 秒内备库无法查询数据，60 秒后数据查询成功。

• 使用延迟备库恢复数据

postgres=# select now(); 
 now 
------------------------------- 
 2023-05-07 13:40:36.503161+08 
(1 row) 

--主库上删除 t1 表 
drop table t1; 

--从库查看这张表依然存在，并且数据也存在 
select * from t1;

• 在删除事件发生之后，马上在延迟备库上暂停 wal 恢复

SELECT pg_wal_replay_pause();

暂停备库可以避免备库重放 drop 操作。如果需要更多时间进行诊断，这个操作就非常有

用。

恢复方法是让延迟备库恢复到 drop 发生之前。在这个例子中，我们大致知道 drop 的物

理时间。从 postgresql.conf 中删除了 recovery_min_apply_delay，并添加了

recovery_target_time。

--停止备库 
pg_ctl stop 
--修改配置参数 
#recovery_min_apply_delay 
recovery_target_time = '2023-05-07 10:42:31.230278+08' 

--启动备库 
pg_ctl start 

--注销 recovery_target_time 参数 
#recovery_target_time = '2023-05-07 10:42:31.230278+08' 

--查看发现 t2 表还在 
postgres=# \d 
 List of relations 
 Schema | Name | Type | Owner 
--------+------+-------+---------- 
 public | t10 | table | postgres 
 public | t2 | table | postgres 
 public | t3 | table | postgres 
 public | t4 | table | postgres 
 public | t5 | table | postgres 
 public | t6 | table | postgres 
 public | t7 | table | postgres 
 public | t8 | table | postgres 
 public | t9 | table | postgres 
(9 rows) 

--提升为主库 
pg_ctl promote 

--原主库 pg_rewind 
pg_rewind --target-pgdata $PGDATA --source-server='host=pg02 
port=5432 user=postgres password=postgres dbname=postgres' -R

 使用时间戳进行操作时，最好为错误留一点余地。但是余地越大，数据丢失就越多。如果

备库恢复超出实际的事件时间戳，它也会重放 drop 操作，我们将不得不重新开始（或者

使用备份来执行 PITR）。

重新启动延迟的 PostgreSQL 实例后，可以看到很多 WAL 段被重放，直到达到目标事务

时间。

当重放时间戳不再发生变化时，我们就知道恢复已经完成了。我们可以考虑设置

recovery_target_action，以便在重放完成后关闭、提升或暂停实例（默认为暂停）。

recovery_min_apply_delay 参数对同步复制的影响

警告： 当 synchronous_commit 设置为 remote_apply 时， 同步复制 会受此设置的影响;

每个 COMMIT 都需要等待被应用。