PostgreSQL 灾难恢复选项

PostgreSQL 灾难恢复选项

我的客户有一个相当大的 PostgreSQL 数据库(总“数据”文件夹大小为 200G),我们正在制定灾难恢复计划。到目前为止,我们已经确定了三种不同类型的灾难:硬件故障、负载过大以及由于错误执行了错误的迁移(如 DELETE 或 ALTER TABLE DROP COLUMN)而导致的意外数据丢失。

前两种类型似乎很容易缓解,但我们无法为第三种类型制定良好的缓解计划。我建议使用 ZFS 和频繁(每小时)快照,但“ZFS”现在意味着“OpenIndiana”,而我们的 Ops 工程师对此没有太多专业知识,因此使用 OpenIndiana 会带来另一个风险。同事们试图说服我,从 PostgreSQL PITR 备份恢复的速度可以与从 ZFS 快照恢复一样快,但我非常怀疑重放 50G 的存档 WAL 是否可以被认为是“快速的”。

我们还缺少什么其他选择?ZFS 是唯一可行的选择吗?我们能在 Linux 环境中获得快速的 Pg DB 恢复时间吗?

答案1

为什么 FreeBSD 不是运行 ZFS 和 PostgreSQL 的可行选择?FreeBSD ZFS 开发人员与 Illumos 团队合作非常密切,最近 Pawel Jakub Dawidek(第一个将 ZFS 移植到 FreeBSD 的人)补充道SSD TRIM 对 ZFS 的支持。这很可能也会很快添加到 Illumos ZFS 代码中。

FreeBSD 和 ZFS 的另一个优点是几何光学框架。在 Solaris 上,当将整个磁盘添加到 ZFS 池时,ZFS 会自动启用其写入缓存。当 ZFS 仅管理磁盘的离散切片时,不会执行此操作,因为它不知道其他切片是否由非写入缓存安全文件系统(如 UFS)管理。FreeBSD 实现可以处理分区的磁盘刷新,这要归功于其几何光学框架,因此不受这个限制。

答案2

我建议您看一下 Barman,它是 PostgreSQL 的备份和恢复管理器,由我们编写,在 GNU GPL 3 条款下作为开源提供。为了让您有个了解,我们在比您的数据库更大的数据库(7 TB)上使用它。版本 1.0 已于 7 月发布。目前已经有 RPM 版本,Debian 软件包正在开发中(Barman 将包含在 Ubuntu 12.10 中)。有关更多信息:www.pgbarman.org

答案3

重播已存档的 WAL 是这里最好的选择,并且很可能是最快的。

这是最好的,因为您可以获得整个时间线。完全不会丢失数据。使用所有类型的快照,您都会丢失数据。每小时快照意味着最坏的情况是您会丢失 1 小时的数据库更改(灾难发生在下一个快照之前)。

此外,如果您进行物理(而非逻辑 - 也需要数据库快照,最适合恢复已删除的表等)恢复,它是在块级别完成的,而且速度非常快。

相关内容