测试/验证日志-发货备份

Question

我们最近在一个包含两个PostgreSQL 8.4辅助服务器的数据中心遭遇了电源/连接中断，通过日志传送复制远程备份我们的两个主服务器。后备电源维持了他们的生命，但他们在两天多一点的时间里没有收到WAL文件。在我们再次恢复连接之前，两场初选的积压已经接近3500次。

当我查看两个次要文件上的~postgres/data/pg_log日志时，我可以在当前日志中看到，当我们重新联机时要处理的第一个WAL段是从中断开始之日开始进入日志文件的最后一个非常连续的日志段。看上去我们什么都没错过，第二次的时间更短了一天。

但我想核实一下。最有效地缓解我的偏执的方法是再次中断连接，这样初级计算机就可以开始缓冲WAL文件，将辅助机器隔离起来，运行足够严格的只读查询来满足自己备份数据的完整性，然后将次要设备恢复到持续恢复模式，最后恢复连接。

这可行吗？或者，促进和处理查询，甚至只读查询，是否足以改变二级数据库，使其以后无法恢复连续恢复？

我意识到这不是流复制的问题，但8.4没有这种能力。

Answer 1

在将从数据库集群引入独立的读写模式(通过recovery_command内部的内部逻辑或在不使用recovery.conf的情况下重新启动它)之后，很难将其还原为从属数据库。

如果可以，请使用文件系统级快照。这将是最简单的方法，因为您可以在不复制整个数据目录的情况下将集群还原到已知的状态。

或多或少，这就是测试从属程序的逻辑：

stop_postgres()
make_pgdata_filesystem_snapshot()
remove_recovery_conf()
start_postgres()
run_testing()
stop_postgres()
revert_pgdata_fs_snapshot()
start_postgres()

如果您没有文件系统快照，您将需要整个集群的本地副本(rsync将很好地维护这一点)。唯一的缺点是磁盘空间的使用，需要更多的时间。

rsync_pgdata_to_local_copy()
stop_postgres()
rsync_pgdata_to_local_copy()
remove_recovery_conf()
start_postgres()
run_testing()
stop_postgres()
rsync_pgdata_from_local_copy()
start_postgres()

Answer 2

重放过程将不只是跳过日志文件。如果它找不到它需要的东西，它就不会继续，除非有人做了一些激烈的事情，比如运行pg_resetxlog或手动编辑二进制文件。

一旦升级到待机状态，就不能再降级了。在较新的版本中，有pg_rewind，但如果没有广泛的第一手测试，我也不会使用它，而且您似乎比我更不愿意冒险。

您可以很容易地做的就是克隆备份，并推广克隆。然后在完成测试时丢弃它。您所需要的只是暂时分配一台机器和存储空间。但真的我不认为你需要做任何事。腐败总是有可能发生的，但是由于这种特殊的连接中断而导致的腐败将在我的担忧之列。远低于你正在运行的一个版本，这是4年后的EOL。