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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
