【问题标题】:Is it possible to restore db from WALs twice?是否可以从 WAL 中恢复 db 两次?
【发布时间】:2019-10-10 08:07:27
【问题描述】:

我有一个主数据库服务器,WAL 定期存档在 s3 上。所以 s3 有一个包含所有相应最新 WAL 的数据库的“快照”。 我有另一个(本地)数据库服务器,我想定期 更新为主数据库服务器的实际状态。 所以我曾经从 s3 复制“主”目录并使用 restore.conf 从 s3 应用所有 WAL 我在这个文件中唯一改变的是:

restore_command = 'aws s3 cp s3://%bucketName%/database/pg_wal/%f %p'

成功了。 一段时间后,我想将 s3 中的所有最新 WAL 应用到与主数据库服务器“更加同步”。 有没有可能以某种方式做到这一点?我很清楚,我没有对我的“复制”数据库服务器进行任何更新或写入。当我尝试以 与以前完全相同的方式进行操作时,我收到了下一个错误(来自 stderr):

fatal error: An error occurred (404) when calling the HeadObject 
operation: Key "database/pg_wal/00000001000001EF0000001F" does not 
exist
fatal error: An error occurred (404) when calling the HeadObject 
operation: Key "database/pg_wal/00000002.history" does not exist
fatal error: An error occurred (404) when calling the HeadObject 
operation: Key "database/pg_wal/00000001.history" does not exist
fatal error: An error occurred (403) when calling the HeadObject 
operation: Forbidden
fatal error: An error occurred (403) when calling the HeadObject 
operation: Forbidden
fatal error: An error occurred (403) when calling the HeadObject 
operation: Forbidden
fatal error: An error occurred (403) when calling the HeadObject 
operation: Forbidden
fatal error: An error occurred (403) when calling the HeadObject 
operation: Forbidden

这是对我的程序的更详细描述:

我在 s3 上有两个目录:basebackuppg_walbasebackup 包含 baseglobalpg_logicalpg_multixactpg_xactPG_VERSIONbackup_label 文件。

当我第一次恢复它时,我会执行以下操作:

  1. 停止 postgres

  2. aws s3 sync s3://%bucketname%/basebackup ~/10/main

  3. mkdir~/10/main 中的空目录

  4. recovery.conf.sample复制到~/10/main/recovery.conf

  5. 如上编辑recovery.conf

  6. 启动 PostgreSQL

当我在一段时间后再次这样做时,我正在执行步骤 1、4、5、6 并获得描述的结果。

可能,我需要以某种方式指定从 s3 存储桶恢复的第一个 WAL?因为我们之前已经恢复了其中的一些。还是根本不可能?

【问题讨论】:

  • 好的,这意味着在第一次恢复之后,备份作为一个独立的数据库出现了。然后你不能继续恢复它。所以关于你如何让它再次尝试恢复存在一些谜团。你能解释一下吗?
  • @LaurenzAlbe。我的意思是,我的数据库和原始数据库之间的区别只是几个 WAL 文件,我想从 s3 中恢复。考虑到我的数据库自第一次恢复以来根本没有改变,这是不可能的吗?
  • 我明白了。缺少的链接是您如何让数据库在步骤 6 之后再次恢复(并失败)。这是不可能的,因为backup_labelrecovery.conf 将被重命名。

标签: postgresql amazon-s3 backup wal


【解决方案1】:

您的程序似乎有很多问题:

  • 完整的备份不仅包含您上面列出的文件和目录,还包含完整数据目录(pg_wal/pg_xlog 可以为空)。

  • 第一次恢复后,PostgreSQL 会选择一个新的时间线,重命名backup_labelrecovery.conf 并作为常规数据库出现。

    您无法继续恢复此类数据库。我不知道你究竟做了什么才能再次进入恢复模式,但你一定是坏了一些东西。

一旦数据库完成恢复,进一步恢复的唯一方法是再次恢复初始备份并从头开始恢复。

您是否考虑过对recovery_target_action = 'pause' 使用时间点恢复?然后 PostgreSQL 将保持在恢复模式,您可以对数据库运行查询。要继续恢复,请定义新的恢复目标并重新启动服务器。

【讨论】:

  • 谢谢!现在它变得更清楚了。我的最后一个问题:当我们使用 recovery_target_action 时,postgres 是否能够以某种方式了解哪些 WAL 应该在以下时间恢复?比方说,在第一次恢复之前,我的 s3 上有 50 个 WAL,它们已成功恢复。一段时间后,还有 100 个 WAL(总共 150 个),当恢复开始时,postgres 应该以某种方式理解然后我们需要跳过 s3 上的前 50 个 WAL,只应用最新的 100 个。这种情况可以用一些 recovery_target_* 处理吗?
  • 这会自动发生。 PostgreSQL 执行重启点(恢复模式下的检查点),恢复将从最近的重启点恢复。
  • 那么,出于好奇:您做了什么让 PostgreSQL 第二次恢复?
  • 上面的步骤 4-6。但它实际上失败了(这就是本主题的内容),这就是我在这里的原因:)。
  • 第一次recovery完成后,没有backup_label,所以PostgreSQL不会再进入recovery,所以restore_command没有被使用,所以你不能得到你的错误信息报告。这就是让我感到困惑的地方。您是否以某种方式创建了一个新的backup_label
猜你喜欢
  • 2016-03-16
  • 1970-01-01
  • 2017-04-26
  • 1970-01-01
  • 1970-01-01
  • 2014-01-11
  • 1970-01-01
  • 1970-01-01
  • 2018-05-16
相关资源
最近更新 更多