主页 / dba / 问题 / 203649
Accepted
Clovis_Sangrail
Asked: 2018-04-12 07:54:36 +0800 CST

测试/验证日志传送备份

  • 772

我们最近在一个装有两台 PostgreSQL 8.4 辅助服务器的数据中心遭遇了电源/连接中断，这些辅助服务器通过日志传送复制远程备份我们的两个主要服务器。备用电源使他们得以存活，但他们在两天多一点的时间里没有收到 WAL 文件。在我们再次恢复连接之前，两个初选的积压接近 3500。

当我查看~postgres/data/pg_log两个辅助节点上的日志时，我可以在当前日志中看到当我们重新联机时要处理的第一个 WAL 段是在最后一个进入日志后的数字连续的下一个从中断开始之日起归档。看来我们什么都没漏，副手不到一天就被追上了。

但我想验证一下。最有效地缓解我的偏执狂的方法是再次断开连接，这样主节点将开始缓冲 WAL 文件，将辅助机器隔离地提升为主节点，运行足够严格的只读查询以使我自己对备份数据的完整性感到满意，然后将辅助设备重新置于连续恢复模式并最终恢复连接。

那可行吗？或者查询的提升和处理，即使是只读的查询，是否会充分改变辅助数据库，以至于它之后无法恢复连续恢复？

我意识到这不会成为流复制的问题，但 8.4 不具备该功能。

postgresql backup

2 个回答

  1. Best Answer

    将从属数据库集群置于独立读写模式后（通过内部逻辑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()
    • 1

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

    一旦提升备用，就不能再次降级。在较新的版本中，有pg_rewind，但如果没有广泛的第一手测试，我什至不会使用它，而且你似乎比我更厌恶风险。

    您可以很容易地做的就是克隆备用数据库，然后提升克隆。然后在完成测试后将其丢弃。您所需要的只是临时分配一台机器和存储。但实际上，我认为您不需要做任何事情。总是存在损坏的可能性，但由于这种特殊的连接中断咒语而导致的损坏将在我的担忧列表中排在最后。远低于您运行的版本是 EOL 4 年后的事实。

    • 1

相关问题