我正在尝试在单独的节点上进行主数据库的夜间恢复.我想通过使用最新的WAL文件进行每周完整恢复和夜间恢复.

在主人身上我有

wal_level = hot_standby
archive_command = 'wal-e --s3-prefix=s3://... wal-push %p'

我做了一个完整的备份：

wal-e --s3-prefix s3://... backup-push <pg data>

在备份节点上我做了：

PGDATA=.. initdb
wal-e backup-fetch $PGDATA LATEST

这工作,我能够连接和选择数据.尼斯.

因此,为了让它使用最新的WAL档案,我添加了一个$PGDATA / recovery.conf：

restore_command = 'wal-e --s3-prefix ... wal-fetch "%f" "%p"'
standby_mode = 'off'

当启动服务器时我希望它继续前进并在非恢复模式启动之前查找要使用的WAL段,但我得到了这个：

LOG:  database system was interrupted; last known up at 2015-03-21 12:20:50 CET
wal_e.operator.backup INFO     MSG: begin wal restore
        STRUCTURED: time=2015-03-21T12:16:38.820461-00 pid=23630 action=wal-fetch key=s3://.../wal_005/00000005.history.lzo prefix=...
/ seg=00000005.history state=begin
lzop: <stdin>: not a lzop file
wal_e.blobstore.s3.s3_util WARNING  MSG: could no longer locate object while performing wal restore
        DETAIL: The absolute URI that could not be located is s3://.../wal_005/00000005.history.lzo.
        HINT: This can be normal when Postgres is trying to detect what timelines are available during restoration.
        STRUCTURED: time=2015-03-21T12:16:39.829223-00 pid=23630
wal_e.operator.backup INFO     MSG: complete wal restore
        STRUCTURED: time=2015-03-21T12:16:39.830287-00 pid=23630 action=wal-fetch key=s3://.../wal_005/00000005.history.lzo prefix=.../ seg=00000005.history state=complete
LOG:  starting archive recovery
wal_e.operator.backup INFO     MSG: begin wal restore
        STRUCTURED: time=2015-03-21T12:16:39.900355-00 pid=23638 action=wal-fetch key=s3://.../wal_005/00000005000000050000009D.lzo prefix=.../ seg=00000005000000050000009D state=begin
lzop: <stdin>: not a lzop file
wal_e.blobstore.s3.s3_util WARNING  MSG: could no longer locate object while performing wal restore
        DETAIL: The absolute URI that could not be located is s3://.../wal_005/00000005000000050000009D.lzo.
        HINT: This can be normal when Postgres is trying to detect what timelines are available during restoration.
        STRUCTURED: time=2015-03-21T12:16:40.896215-00 pid=23638
wal_e.operator.backup INFO     MSG: complete wal restore
        STRUCTURED: time=2015-03-21T12:16:40.899320-00 pid=23638 action=wal-fetch key=s3://.../wal_005/00000005000000050000009D.lzo prefix=.../ seg=00000005000000050000009D state=complete
WARNING:  WAL was generated with wal_level=minimal, data may be missing
HINT:  This happens if you temporarily set wal_level=minimal without taking a new base backup.
LOG:  consistent recovery state reached at 5/9D009DA8
LOG:  record with zero length at 5/9D009DA8
LOG:  redo is not required

所以问题是;

>我的方法根本错了吗？有没有其他方法让这个工作？
> PostgreSQL声称我有wal_level = minimal,我如何检查生成的WAL文件的级别？在主服务器上,我检查它的实际设置时得到这个：

select * from pg_settings where name='wal_level';
-[ RECORD 1 ]------------------------------------------------
name       | wal_level
setting    | hot_standby
unit       |
category   | Write-Ahead Log / Settings
short_desc | Set the level of information written to the WAL.
extra_desc |
context    | postmaster
vartype    | enum
source     | configuration file
min_val    |
max_val    |
enumvals   | {minimal,archive,hot_standby}
boot_val   | minimal
reset_val  | hot_standby
sourcefile | /.../postgresql.conf
sourceline | 155

编辑：在master上添加archive_command的详细信息

解决方法:

wal-e backup push 

不会将任何wal文件推送到s3.

所以这个备份大多是不可恢复的.

使用

archive_command = '... wal-e wal-push %p'

在master上使这个备份可用.