为什么WAL for PITR需要Postgres basebackup？

Question

我正在阅读下面的article来设置PITR。我感到困惑的一件事是，为什么本文建议在设置连续WAL存档之后执行basebackup (完整集群备份)。我以为WAL才是真正的数据？所以，如果我有来自time t=0的WAL，为什么我还需要任何其他备份？我曾在另外两个postgres社区询问过，但对这一点的回应是“因为在实践中你不会有来自time t=0的WAL”，或者说还不知道为什么两者都是真正需要的。无论如何，只是好奇，谢谢！

Answer 1

WAL包含类似这样的信息：“在文件X的块Y中，在偏移量z处写入这13个字节”或“将文件X扩展1个8kB块”。

您总是需要一些起点来恢复WAL：

具有崩溃恢复功能的

• ，这是最新的检查点，其位置已写入控制文件。

• 使用PITR时，将从运行基本备份时创建的backup_label文件中获取检查点，并包含启动备份的检查点。

如果你没有一个起点，你怎么能恢复呢？

也许你的误解是数据库最初是空的，所以你需要的只是一开始的WAL文件。但事实并非如此:即使在initdb之后，数据库也已经包含目录表和元数据。

Answer 2

存在一个伪随机Database system identifier，它在不同的数据库系统之间是不同的。这既记录在pg_controldata中，也记录在每个WAL段中，并且必须匹配才能将WAL重放到服务器中。在我看来，多次运行initdb得到的目录与pg_controldata和pg_wal/000000010000000000000001 (当然还有文件系统时间戳)的内容完全相同。

因此，如果您想在处理链锯时遇到流量，您可以跳过基本备份，然后只需运行一个新的initdb，并尝试将系统标识符重装到新的pg_controldata文件中。

享受把自己炸飞的感觉。如果成功，您的奖励将是不必进行初始基本备份，这将压缩到1.35MB。

这是一个紧跟在pg_upgrade之后的实际问题。新系统必须被认为是易受攻击的，直到采取新的基本备份(它可能比1.35MB大得多，但比1.35MB慢得多)。如果您使用pg_upgrade -k，这个新的基本备份可能构成完成升级所需的绝大多数时间窗口。