Question

Hy家伙，我有一个带有许多数据库的postgresql 8.3服务器。

实际上，我计划使用脚本备份这些数据库，该脚本将所有备份存储在具有相同名称的db的文件夹中，例如：

/mypath/backup/my_database1/
/mypath/backup/my_database2/
/mypath/backup/foo_database/

每天我每2小时进行1次转储，每天覆盖文件...例如，在my_database1文件夹中我有：

my_database1.backup-00.sql  //backup made everyday at the 00.00 AM
my_database1.backup-02.sql  //backup made everyday at the 02.00 AM
my_database1.backup-04.sql  //backup made everyday at the 04.00 AM
my_database1.backup-06.sql  //backup made everyday at the 06.00 AM
my_database1.backup-08.sql  //backup made everyday at the 08.00 AM
my_database1.backup-10.sql  //backup made everyday at the 10.00 AM
[...and so on...]

这就是我实际上确保自己能够恢复每个数据库失去至少2小时数据的方式。

2小时看起来仍然太多了。

我已经看了一下这个文件的postgresql pitr，但是，这些文件似乎包含所有关于所有我的数据库的数据。

我需要将这些文件分开，就像我分开转储文件一样。

如何？

否则，还有一个易于安装的备份程序可以让我在10秒之前恢复1个备份，但不会每10秒创建一个转储文件？

Answer 1

使用PostgresSQL的一个实例是不可能的。

您可以在多个实例之间划分500个表，每个实例都在不同的端口上进行监听，但这意味着它们不会有效地使用内存等资源（保留内存但在一个实例中未使用但不能被另一个实例使用）。

Slony也不会在这里工作，因为它不会复制DDL语句，比如删除表。

我建议同时做两件事：

继续做你的pg_dump备份，但试着平滑它 - 节流pg_dump io bandwith，所以它不会削弱服务器，并连续运行 - 当它完成最后一个数据库然后立即开始一个;
另外设置PITR。

这样您可以快速恢复单个数据库，但是您可以丢失一些数据。如果您决定不能丢失那么多数据，那么您可以将PITR备份恢复到临时位置（fsync = off和pg_xlog符号链接到ramdisk以获得速度），pg_dump从那里影响数据库并将其恢复到主数据库中。

Answer 2

为什么要分开数据库？

PITR的工作方式是不可能的，因为它适用于整个集群。在这种情况下，您可以做的是为每个数据库创建一个数据目录和一个单独的集群（不推荐使用，因为它需要不同的端口和postmaster实例）。

我认为使用PITR而不是常规转储的好处超过了为每个数据库分别备份，所以也许您可以重新考虑为什么需要将它分开的原因。

另一种方法可能是使用Slony-I设置一些复制，但这需要一个接收数据的单独机器（或实例）。另一方面，通过这种方式，您可以近乎实时地拥有复制系统。

评论更新：

要从错误中恢复，例如删除表格，PITR将是完美的，因为您可以重播到特定时间。但是，对于500个数据库，我理解这可能会带来很多开销。 Slony-I可能不会工作，因为它正在复制。不知道它如何处理表删除。

我不知道你可以采取任何其他方式。我会做的可能仍然是PITR而且不会犯任何错误;）。除了笑话，根据错误的发生频率，这可能是一个解决方案：

将其设置为PITR
准备好备用的第二个实例。
发生错误时，将恢复重播到第二个实例的时间点。
从该实例执行受影响数据库的pg_dump。
在该数据库的生产实例上执行pg_restore。

但是，它需要您准备好第二个实例，无论是在同一台服务器上还是在另一台服务器上（建议使用不同的实例）。此外，恢复时间会稍长，因为它需要您进行一次额外的转储和恢复。

Answer 3

我认为你这样做的方式是有缺陷的。您应该有一个具有多个模式和角色的数据库。然后你可以使用PITR。但是，PITR不是转储的替代品。

Postgresql PITR备份：处理多个数据库的最佳实践？

3 个答案: