我们有一个 PostgreSQL 13 复制集群，其中一个备用服务器设置了recovery_min_apply_delay“x hr”，这在数据损坏的情况下很有用。
对于主服务器上发生意外删除但尚未应用于备用服务器的情况。 在这种情况下，我尝试通过删除WAL 重放延迟并添加recovery_target_time到删除发生之前的某个点来从备用服务器中提取数据。
到目前为止，我已经成功了，但是一旦我将数据从备用服务器拉到主服务器（我正在考虑 postgres_fdw），我就需要恢复复制。但是当我运行时pg_wal_replay_resume()，它正在创建一个新的时间线，并且不再位于复制集群中。
除了使用之外，还有其他方法可以重放 WAL 吗recovery_target_time？
举个例子来说明一下我想要实现的目标，
假设 recovery_min_apply_delay=2hr ，意外删除发生在凌晨 03:50，此时待机时提交的事务是凌晨 01:50 或之前发生的事务。如果我再等 2 小时，并且在凌晨 05:49 时，如果我能够暂停待机 WAL 重放，我将能够看到“删除之前”的数据快照。然后我将使用 postgres_fdw 从待机中提取数据。
我如何以精确系统的方式实现“正确之前”？此外，我还可以恢复 WAL 重放。
不，这是不可能的，而且这确实是一个非常糟糕的主意。如果您保持相同的时间轴，PostgreSQL 无法将 WAL 与两个“平行宇宙”区分开来：一个是您删除了表的宇宙，另一个是您没有删除表的宇宙。这可能会导致有趣的数据损坏。
但你根本不需要这个。
如果发生意外，只需将备用服务器设置
recovery_target_time为开启状态并保持recovery_target_action开启pause。当重播暂停时，从备用服务器中提取所需的数据。然后recovery_target_time再次移除，重新加载并恢复恢复。无需提升备用服务器！