Cheryl Grant wrote:
>>>   2844LOG:  starting point-in-time recovery to 2013-02-26 12:53:00+11
>>>   2844LOG:  restored log file "000000010000017D00000056" from archive
>>>   2844LOG:  unexpected pageaddr 17D/2E000000 in log file 381, segment 86,
>>> offset 0
>>>   2844LOG:  invalid checkpoint record
>>>   2844FATAL:  could not locate required checkpoint record

>> That indicates that the WAL file 000000010000017D00000056 is
>> broken.  Are you sure that it is from the PostgreSQL server
>> you backed up?  How did you archive the WAL files?

> I'm doing a pg_basebackup to create the instance with -x specified so some of 
> the logs are in the
> pg_xlog directory after the backup. It always seems to fall over with the 
> same error on the first log.
> I've tried this numerous times with different backups and it always fails on 
> the first log.

Ah, but what the above log entry says is that it
took the WAL file from the archive location and
copied it into pg_xlog.

So the WAL file created by the -x switch of
pg_basebackup was overwritten with a file from
the archive.

Does the archive contain a different (= wrong)
copy of the WAL file?

> I've used the same method to create a hot standby which works, but only 
> because streaming replication
> is getting the data across. But this won't work in a disaster recovery 
> situation.

Even with streaming replication that should not
work, if the problem is a bad WAL file in the archive.

> My backup command for the primary WAL logs is a script. Here is the contents 
> of the script:
> 
> ls -1 $PGDATA/pg_xlog | while read f; do
> {
>   if [ -f $PGDATA/pg_xlog/$f ] ; then
>   if [ ! -f $LOGPATH/$f ] ; then
>      echo "$PGDATA/pg_xlog/$f" >> $LOGFILE
>      cp $PGDATA/pg_xlog/$f $LOGPATH
>      status=$?
>      echo status=$status >> $LOGFILE
>      scp $LOGPATH/$f $SCPHOST:$LOGPATH &
>   fi
>   fi
> } done;

That's not your archive_command, right?
At what points is this script run?
Could it have copied an incomplete WAL file to the archive?

The good way to archive WAL files is to specify an
appropriate archive_command in postgresql.conf.
Then each WAL file is archived as soon as it is full,
and the PostgreSQL server knows if archiving worked or not.

Yours,
Laurenz Albe


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Reply via email to