1

环境: 800GB Postgres 数据库(OpenSuse)

正常恢复过程:

  • 你有 pg_basebackup 来恢复(比方说:每周六)
  • 你有从上周六到今天的WAL文件
  • 第一:使用 pg_basebackup 恢复
  • 然后:使用WAL文件更新数据库以获得最新数据。(带有recovery.conf)

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

  • 恢复完整的数据库-vm(昨天站着)
  • 添加 WAL 文件(恢复)以使此 vm-clone 保持最新。

现在我已经完成了:

  • 我恢复了一个虚拟机
  • 创建recovery.conf

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

  • rcpostgresql 启动

我收到以下错误:

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 文件名)

有什么办法可以让这个工作吗?

4

2 回答 2

0

根据您的错误,我假设您跳过了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.confrestore_command = 'cp /.../%f %p'
    3. rcpostgresql 启动
    4. 让人们知道它是否有效

你也可能想在这里阅读有关 pg_control、chechpoints 和恢复序列的信息

于 2017-05-09T20:36:58.680 回答
0

几天后,我能够得到这个工作。@Vao Tsun 的帮助将我带入了正确的方向,但遗憾的是没有必要。

如何使用 WAL 文件恢复 Postgres 数据库并完成 VM 备份 | 恢复:

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