Re: restoring wal archive and pg_xlog dir

From: Jeff Frost <jeff(at)frostconsultingllc(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: restoring wal archive and pg_xlog dir
Date: 2005-06-23 22:50:03
Message-ID: Pine.LNX.4.63.0506231546240.21285@discord.dyndns.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Thu, 23 Jun 2005, Simon Riggs wrote:

>> I also noticed that if there is not at least one wal archive available in
>> the archive or the pg_xlog dir, the restore errors out and exits. So the
>> base backup is really not complete without at least one wal archive
>> following it. Is this by design?
>
> That was the bit I didn't. Fix partially implemented and I am to submit
> for 8.1, godspeed my typing fingers. There's a simple workaround if you
> have a low transaction rate system: load up enough data to trip into the
> next xlog.

Simon, thanks for the clarification! What we have is a low transaction rate
system which rolls over about 5 xlogs a day or so. I'm trying to write a nice
automated script that anyone can run to restore the DB from a pitr archive and
base backup should disaster strike and I'm not around, so I'm attempting to
sort out what exactly that might entail. It looks like this is what I need to
have a complete restorable data dir:

So, .backup file is named: 000000010000000500000051.00FB6C60.backup, then I
need at least the following to do a proper restore:

* pg_xlog/000000010000000500000051
* PGDATA base backup

and then any archived wal files that come after 51 if none happen before the
next base backup?

Thanks for all the help guys!

--
Jeff Frost, Owner <jeff(at)frostconsultingllc(dot)com>
Frost Consulting, LLC http://www.frostconsultingllc.com/
Phone: 650-780-7908 FAX: 650-649-1954

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Jeff Frost 2005-06-23 23:01:44 Re: restoring wal archive and pg_xlog dir
Previous Message Vladimir Yevdokimov 2005-06-23 21:48:19 Re: psql copy errors