主页 / dba / 问题 / 3365
Accepted
Jamess
Asked: 2011-06-18 03:18:55 +0800 CST

Postgresql - 使用 recovery.conf 恢复

  • 772

我正在尝试使用 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 档案恢复时，我遇到了同样的问题。此外，我可以在两台服务器上始终如一地重现此问题。

因此，如果我需要创建接近当前时间的备份，我会使用比当前时间晚 3.5 小时的 recovery_target_time 并使用 recovery.conf 启动数据库

postgresql restore

2 个回答

  1. Best Answer

    免责声明：我不是 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 将时区默认为操作系统的时区。如果 WAL 文件的内部时间戳也包含时区，则必须将 postgres 中设置的时区与 WAL 文件的时区对齐。

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

    恢复的默认行为是沿进行基本备份时的当前时间线进行恢复。如果您想恢复到某个子时间线（即，您想返回到恢复尝试后自身生成的某个状态），您需要在“recovery.conf”中指定目标时间线 ID。您无法恢复到早于基本备份分支的时间线。

    更新 2011-06-20 15:08 EDT

    这直接来自在线文档。请仔细检查一下，看看您是否遗漏了任何 WAL 文件。如果您在新服务器上设置 WAL 文件等待的时间过长，postgres 可能在启动时已将其删除。您可能需要找到那些 WAL 文件。查看它们是否位于旧服务器的 pg_xlog 文件夹中。

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

    1. 停止服务器，如果它正在运行。

    2. 如果您有空间这样做，请将整个集群数据目录和任何表空间复制到一个临时位置，以备日后需要它们时使用。请注意，此预防措施将要求您的系统上有足够的可用空间来保存现有数据库的两个副本。如果你没有足够的空间，你至少需要复制集群数据目录的 pg_xlog 子目录的内容，因为它可能包含在系统宕机之前没有归档的日志。

    3. 清除集群数据目录下以及您正在使用的任何表空间的根目录下的所有现有文件和子目录。

    4. 从基本备份中恢复数据库文件。请注意，以正确的所有权（数据库系统用户，而不是 root！）和正确的权限来恢复它们。如果您正在使用表空间，您应该验证 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 恢复为正常来让您的用户进入。

    • 4

  2. 在 PostgreSQL 中，可能并不表示“印度标准时间” ，IST具体取决于'timezone_abbreviations'. postgresql.conf它应该设置为'India'forIST以在此处根据需要进行解释。

    • 3

相关问题