在克隆的虚拟机上使用 WAL 进行 Postgres 还原/更新，而不是使用基本备份

Question

环境：800GB Postgres-Database (OpenSuse)

正常恢复过程：

• 您必须pg_basebackup恢复(假设：每个星期六)
• 你有从上周六到今天的WAL文件
• 首先：使用pg_basebackup还原
• 然后：使用WAL文件更新数据库以获得最新数据。(与恢复.conf)

我的想法：
为什么要每周做大pg_basebackup，并通过互联网将 800GB 复制到 NAS，当您每天都使用一些备份软件进行增量备份时。

• 还原完整的数据库虚拟机(昨天)
• 添加 WAL 文件(还原)以使此虚拟机克隆保持最新。
  

现在我已经完成了：

• 我还原了虚拟机

• 创建恢复

  restore_command = 'cp/.../%f %p'

• rcpostgresql start

我收到以下错误：

2017-05-09 16:46:07.780 CEST [2938]: [1-1] user=,db=,app=,client= LOG:  database system was shut down at 2017-05-09 16:45:47 CEST
2017-05-09 16:46:07.780 CEST [2938]: [2-1] user=,db=,app=,client= LOG:  starting archive recovery
2017-05-09 16:46:08.588 CEST [2952]: [1-1] user=[unknown],db=[unknown],app=[unknown],client=[local] LOG:  connection received: host=[local]
2017-05-09 16:46:08.588 CEST [2952]: [2-1] user=postgres,db=postgres,app=[unknown],client=[local] FATAL:  the database system is starting up
2017-05-09 16:46:09.391 CEST [2938]: [3-1] user=,db=,app=,client= LOG:  restored log file "000000010000070D0000008A" from archive
2017-05-09 16:46:09.434 CEST [2938]: [4-1] user=,db=,app=,client= LOG:  contrecord is requested by 70D/8A000028
2017-05-09 16:46:09.434 CEST [2938]: [5-1] user=,db=,app=,client= LOG:  invalid primary checkpoint record
2017-05-09 16:46:09.434 CEST [2938]: [6-1] user=,db=,app=,client= LOG:  invalid secondary checkpoint link in control file
2017-05-09 16:46:09.434 CEST [2938]: [7-1] user=,db=,app=,client= PANIC:  could not locate a valid checkpoint record
2017-05-09 16:46:09.434 CEST [2936]: [4-1] user=,db=,app=,client= LOG:  startup process (PID 2938) was terminated by signal 6: Aborted
2017-05-09 16:46:09.434 CEST [2936]: [5-1] user=,db=,app=,client= LOG:  aborting startup due to startup process failure

pg_resetxlog后，下一个 WAL 文件被恢复。 我得到同样的错误(下一个 wal 文件名)

有什么办法可以让它工作吗？

Answer 1

从你的错误中，我假设你跳过了pg_start_backup.否则，您应该缺少检查点：

pg_start_backup接受任意用户定义的标签 备份。(通常，这是备份转储的名称 文件将被存储。在独占模式下使用时，该函数写入 备份标签文件 (backup_label)，如果 pg_tblspc/目录，将表空间映射文件 (tablespace_map) 放入 数据库集群的数据目录，执行检查点，然后 以文本形式返回备份的起始事务日志位置。

按照逻辑，顺序应该是这样的：

• 备份：

  1. 前一天 - 就在 VM 复制之前，运行select pg_start_backup('some label')(确保它返回位置 - 创建保存点可能需要很长时间，或者以 IO 峰值价格强制快速创建)
  2. 虚拟机备份
  3. select pg_stop_backup()
• 恢复：
  1. 我还原了虚拟机
  2. 创建 recovery.conf withrestore_command = 'cp /.../%f %p'
  3. rcpostgresql start
  4. 让人们知道它是否有效

另外，您可能想在此处阅读有关pg_control，车手点和恢复序列的信息。

Answer 2

几天后，我能够让它工作。 @Vao Tsun的帮助使我进入正确的方向，但遗憾的是没有必要。

如何使用 WAL 文件恢复 Postgres-Database 并完成虚拟机备份 |恢复：

• 备份：
  • [ 也许创建一个新的 postgres 检查点。 对我来说没有必要，但我的最后一个检查点还不太旧; 对于检查点，有一种没有 pg_start_backup() 的直接方法
  • 对包含 postgres 数据库的 VM 进行简单备份。 完整/增量 ->您的选择。(我在 VM 运行时执行此操作)
  • select pg_start_backup('some label')不是必需的.
    只是普通备份，[之前可能有检查点]
• 还原虚拟机：
  • 请勿自动引导此虚拟机。您需要确保postgres 不会自动启动。如果你有，你可以使用特殊的引导模式来做到这一点，用live-linux-CD重命名postgres二进制或数据目录，或者有一个脚本，它会检查系统是否已恢复，所以postgres不应该启动。
  • 引导虚拟机
  • [ 如果禁用 postgres 有效，请检查pg_log文件。 ->没有新的日志文件 ]
• 恢复数据库：在
  • $pgdata目录中创建 recovery.conf：
    restore_command = 'cp /[path_to_your_wal_backups]/%f "%p"' recovery_target_timeline = 'latest'
  • 开始发布
  • 请参阅pg_log恢复 WAL 文件是否有效
  • [ 连接到数据库，并搜索新数据作为上次测试 ]