Postgres restore/update 在克隆的 VM 上使用 WAL 而不是使用 basebackup

Question

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

正常还原过程：

您有 pg_basebackup 恢复时间（假设：每个星期六）
从上周六到今天，您有 WAL 个文件
首先：使用 pg_basebackup
然后：使用 WAL 文件更新数据库以获得最新数据。（recovery.conf）

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

恢复完整的数据库-vm（昨天的站）
添加 WAL 文件（恢复）以使此虚拟机克隆保持最新。

现在我已经完成了：

我恢复了一个虚拟机
创建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-file-name）

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

Answer 1

根据你的错误我假设你跳过了pg_start_backup。否则你 should have missing checkpoint:

pg_start_backup accepts an arbitrary user-defined label for the backup. (Typically this would be the name under which the backup dump file will be stored.) When used in exclusive mode, the function writes a backup label file (backup_label) and, if there are any links in the pg_tblspc/ directory, a tablespace map file (tablespace_map) into the database cluster's data directory, performs a checkpoint, and then returns the backup's starting transaction log location as text.

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

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

您可能还想阅读有关 pg_control、检查点和恢复序列 here 的内容。

Answer 2

几天后，我就能开始工作了。 @Vao Tsun 的帮助将我带入了正确的方向，但遗憾的是没有必要。

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

备份：
- [ 也许创建一个新的 postgres 检查点。对我来说没有必要，但我的最后一个检查站并不太旧；对于检查点，有一种没有 pg_start_backup() ]
- 对包含 postgres 数据库的 VM 进行简单备份。 full/incremental -> 你的选择。（我在 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
- 查看 pg_log 是否可以恢复 wal 文件
- [连接到数据库。并搜索新数据作为上次测试]

Postgres restore/update 在克隆的 VM 上使用 WAL 而不是使用 basebackup

Postgres restore/update with WAL on cloned VM instead of using basebackup

postgresql

backup

restore

wal