Postgres 连续归档和时间点恢复 (PITR)

Posted

技术标签:

【中文标题】Postgres 连续归档和时间点恢复 (PITR)【英文标题】:Postgres Continuous Archiving and Point-in-Time Recovery (PITR) 【发布时间】:2018-04-11 15:11:27 【问题描述】:

我正在尝试在 Postgres 中设置连续存档和时间点恢复 (PITR)。当我通过documentation 它说:

归档命令通常应设计为拒绝覆盖任何预先存在的归档文件。这是一项重要的安全功能,可在出现管理员错误(例如将两个不同服务器的输出发送到同一存档目录)时保持存档的完整性。

但是当我打开一个连接并不时进行一些更改时,我看到同一个 WAL 文件正在多次更改。例如,当我第一次连接数据库并进行一些更改(例如删除或插入一些行)时,它会创建一个名为 000000010000000000000090 的 WAL 文件,并且我的 archive_command 会立即运行。我的 archive_command 是

test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f

这是基于文档,它检查文件是否已经存在于存档目录中,如果存在,它不会复制并且仅当文件不存在时才复制。因此,第一次条件通过并复制文件时,但是当我使用相同的连接进行更多更改时(当我从同一台 PC 重新连接时,我什至遇到相同的问题)原始 WAL 文件正在更改。但是下次复制不起作用,因为文件已经存在。

如果允许发生这种情况,我们可能会丢失备份中的一些更改。任何人都知道任何解决方案,因此它会为每次更改创建一个新文件而不是修改旧文件?

我在本地计算机 (Mac) 上使用 Postgres 版本 10.2。

【问题讨论】:

【参考方案1】:

这真的发生在你身上吗?因为它不应该。

PostgreSQL 将事务日志写入 16MB 大小的“WAL 文件”(WAL 表示 Write Ahead Log)。

每当一个WAL文件满了,日志就会切换到一个新的WAL文件,旧的WAL文件用archive_command归档。

如果archive_command以退出状态0(成功)完成,WAL文件被回收,否则重试归档直到成功。将记录失败。

反正只要没有错误,每个WAL文件只会归档一次

你描述的行为不应该发生。

检查 PostgreSQL 日志以查看是否有来自 archive_command 的错误报告。如果您修复错误情况。将恢复正常运行。

【讨论】:

谢谢。我刚刚检查了 postgres.log 文件(位于 /usr/local/var/log/ 文件夹中),并没有看到任何错误记录在那里。顺便说一句,我现在看到另一个问题。我看到 WAL 文件名随着创建的每个连接而改变,尽管内容如你所说的那样递增。 (当前文件名为 000000010000000000000093 更改为 ..91 和 ..92 后)。我可以看到复制到存档目录的 ..90、..91 和 ..92 文件,但看不到 ..93 版本。再次注意,所有文件内容都相同(递增)。 如何确定文件内容?在这种情况下,什么是“递增”? 我只看文件大小。 文件不同。所有 WAL 文件都预先分配了 16MB。编号决定了 WAL 文件的顺序。每个 WAL 文件只归档一次(除非有错误,并记录)。

以上是关于Postgres 连续归档和时间点恢复 (PITR)的主要内容,如果未能解决你的问题,请参考以下文章

pg_archivecleanup 和流复制

坚如磐石:TiDB 基于时间点的恢复(PiTR)特性优化之路丨6.5 新特性解析

PostgreSQL 9.2 归档恢复后最后重放的 WAL

pgBackRest 的安全权限

技术分享 | 基于 mongo cluster 的 PITR 恢复案例一则

PostgreSQL技术分享公开课:备份恢复与Point-in-Time Recovery(PITR