Postgresql -使用recovery.conf进行恢复

Question

我正在尝试用recovery.conf文件恢复一个数据库，以便及时复制.

在recovery.conf文件中，我添加了一个恢复目标时间，如下所示。

recovery_target_time = '2011-06-16 04:10:00 IST'

但是，在日志中，我可以看到它是否将时间提前了3.5小时至07:40，并且这一次尝试了实际的恢复，而不是我在recovery_target_time中提供的时间。

2011-06-16 12:53:45 IST LOG:  starting archive recovery
2011-06-16 12:53:45 IST LOG:  restore_command = '/app/postgresinstall/bin/pg_standby -l /dbdata/archive %f %p %r'
2011-06-16 12:53:45 IST LOG:  recovery_target_time = '2011-06-16 07:40:00+05:30'
cp: cannot stat `/dbdata/archive/00000001.history': No such file or directory

为什么有3.5小时的差异，而我需要帮助，弄清楚在确定恢复目标时间时发生了什么？

更新:以下是数据库中的时间详细信息

postgres=# SELECT EXTRACT(timezone_hour FROM now()),EXTRACT(timezone_minute FROM now());
 date_part | date_part 
-----------+-----------
         5 |        30
(1 row)

postgres=# select now();
               now                
----------------------------------
 2011-08-12 13:08:19.333068+05:30
(1 row)

OS Date/Time:
postgres@xxxxx:~$ date
Fri Aug 12 13:10:19 IST 2011

当我试图从同一服务器和备份服务器上的WAL档案中恢复时，我也遇到了同样的问题。而且，我可以在这两台服务器上不断地重复这个问题。

因此，如果我需要创建一个接近当前时间的备份，我使用recovery_target_time 3.5小时后的当前时间，并启动DB与recovery.conf

Answer 1

免责声明:我不是一个PostgreSQL DBA，虽然我经常尝试它。

您可能需要检查操作系统和psql中的时区。

在操作系统中运行以下命令：

[postgres@radarPG-db1 ~]$ date
Fri Jun 17 12:55:37 EDT 2011

在psql中，运行以下命令：

postgres=# SELECT EXTRACT(timezone_hour FROM now()),EXTRACT(timezone_minute FROM now());
 date_part | date_part
-----------+-----------
        -4 |         0

postgres=# select now();
              now
-------------------------------
 2011-06-17 12:54:39.195291-04

很多时候，有些人忘记将postgres默认为OS的时区。如果WAL文件还在其内部时间戳中包含时区，则必须将postgres中设置的时区与WAL文件的时区对齐。

需要考虑的其他事项如下：

恢复的默认行为是沿着采取基本备份时的当前时间线进行恢复。如果您想要恢复到某个子时间线(也就是说，您希望返回到某个状态，该状态是在一次恢复尝试之后生成的)，那么您需要在'recovery.conf‘中指定目标时间线ID。无法恢复到比基本备份更早分支的时间线。

更新2011-06-20 15:08东部时间

这是从在线文档中得到的。请看一下这个，看看你是否遗漏了WAL的任何文件。如果您等了太久才在新服务器上设置WAL文件，postgres可能已经在启动时删除了它们。你可能需要找到那些WAL文件。查看它们是否驻留在旧服务器的pg_xlog文件夹中。

使用连续存档备份进行恢复

1. 如果服务器在运行，就停止它。
2. 如果您有这样做的空间，请将整个集群数据目录和任何表空间复制到临时位置，以防以后需要它们。请注意，这种预防措施将要求您在系统上有足够的空闲空间来保存现有数据库的两个副本。如果您没有足够的空间，您至少需要复制集群数据目录的pg_xlog子目录的内容，因为它可能包含在系统崩溃之前没有存档的日志。
3. 清除群集数据目录下的所有现有文件和子目录以及正在使用的任何表空间的根目录下的所有文件和子目录。
4. 从基本备份还原数据库文件。注意，它们是用正确的所有权(数据库系统用户，而不是根用户)恢复的！而且有了正确的许可。如果使用表空间，则应验证pg_tblspc/中的符号链接是否已正确恢复。
5. 删除pg_xlog/中的任何文件；这些文件来自备份转储，因此可能过时，而不是当前文件。如果您根本没有存档pg_xlog/，那么就重新创建它，如果您以前是这样设置它的话，那么要小心地确保将它重新建立为一个符号链接。
6. 如果您在步骤2中保存了未存档的WAL段文件，请将它们复制到pg_xlog/中。(最好是复制它们，而不是移动它们，这样在出现问题时仍然有未经修改的文件，并且必须重新开始。)
7. 在群集数据目录中创建一个恢复命令文件recovery.conf (请参见恢复设置)。您还可能希望临时修改pg_hba.conf，以防止普通用户连接，直到确定恢复工作为止。
8. 启动服务器。服务器将进入恢复模式，并继续读取它需要的归档WAL文件。如果由于外部错误而终止恢复，则可以简单地重新启动服务器并继续恢复。在恢复过程完成后，服务器将recovery.conf重命名为recovery.done (以防止在以后崩溃时意外地重新进入恢复模式)，然后开始正常的数据库操作。
9. 检查数据库的内容，以确保您已恢复到想要的位置。如果没有，请返回到步骤1。如果一切正常，通过将pg_hba.conf恢复到正常状态让用户进入。

Answer 2

在PostgreSQL中，IST可能并不意味着“印度标准时间”，这取决于postgresql.conf中的'timezone_abbreviations‘设置。应该将其设置为'India'，以便在这里按照需要对IST进行解释。