On Fri, Sep 5, 2014 at 7:59 PM,  <[email protected]> wrote:
> Howdy, getting the following error on startup on the standby startup:
>
>  * Starting PostgreSQL 9.3 database server
> * The PostgreSQL server failed to start. Please check the log output:
> 2014-09-06 00:01:35 UTC LOG:  database system was interrupted while in
> recovery at log time 2014-09-05 19:14:04 UTC
> 2014-09-06 00:01:35 UTC HINT:  If this has occurred more than once some data
> might be corrupted and you might need to choose an earlier recovery target.
> 2014-09-06 00:01:35 UTC LOG:  starting archive recovery
> wal_e.operator.backup INFO     MSG: begin wal restore
>         STRUCTURED: time=2014-09-06T00:01:35.754042-00 pid=3435
> action=wal-fetch
> key=s3://*.*.com/backups/db_backups/wal-e/sands-app-01/wal_005/000000010000000100000056.lzo
> prefix=backups/db_backups/wal-e/sands-app-01/ seg=000000010000000100000056
> state=begin
> 2014-09-06 00:01:35 UTC LOG:  incomplete startup packet
> 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://*.*.com/backups/db_backups/wal-e/sands-app-01/wal_005/000000010000000100000056.lzo.
>         HINT: This can be normal when Postgres is trying to detect what
> timelines are available during restoration.
>         STRUCTURED: time=2014-09-06T00:01:36.054987-00 pid=3435
> wal_e.operator.backup INFO     MSG: complete wal restore
>         STRUCTURED: time=2014-09-06T00:01:36.056532-00 pid=3435
> action=wal-fetch
> key=s3://*.*.com/backups/db_backups/wal-e/sands-app-01/wal_005/000000010000000100000056.lzo
> prefix=backups/db_backups/wal-e/sands-app-01/ seg=000000010000000100000056
> state=complete
> wal_e.operator.backup INFO     MSG: begin wal restore
>         STRUCTURED: time=2014-09-06T00:01:36.259396-00 pid=3445
> action=wal-fetch
> key=s3://*.*.com/backups/db_backups/wal-e/sands-app-01/wal_005/000000010000000100000054.lzo
> prefix=backups/db_backups/wal-e/sands-app-01/ seg=000000010000000100000054
> state=begin
> 2014-09-06 00:01:36 UTC FATAL:  the database system is starting up
> 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://*.*.com/backups/db_backups/wal-e/sands-app-01/wal_005/000000010000000100000054.lzo.
>         HINT: This can be normal when Postgres is trying to detect what
> timelines are available during restoration.
>         STRUCTURED: time=2014-09-06T00:01:36.529592-00 pid=3445
> wal_e.operator.backup INFO     MSG: complete wal restore
>         STRUCTURED: time=2014-09-06T00:01:36.531360-00 pid=3445
> action=wal-fetch
> key=s3://*.*.com/backups/db_backups/wal-e/sands-app-01/wal_005/000000010000000100000054.lzo
> prefix=backups/db_backups/wal-e/sands-app-01/ seg=000000010000000100000054
> state=complete
> 2014-09-06 00:01:36 UTC PANIC:  invalid resource manager ID 24 at 1/5401C0F8
> 2014-09-06 00:01:36 UTC LOG:  startup process (PID 3433) was terminated by
> signal 6: Aborted
> 2014-09-06 00:01:36 UTC LOG:  terminating any other active server processes
>
> [fail]
>
>
>  My recovery.conf is just one line:
>
> restore_command  = 'envdir /etc/wal-e.d/env /usr/local/bin/wal-e wal-fetch
> "%f" "%p"'
>
>
> I'm using the root AWS keys for testing so wouldn't seem to be a permissions
> issue... Any help would be appreciated.

Something is seriously wrong.  How are you doing the restore?  Is it
from a clean start?

I also suggest using "standby_mode='on'" in recovery.conf in all situations.

-- 
You received this message because you are subscribed to the Google Groups 
"wal-e" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to