On Sun, 2 Oct 2005, Simon Riggs wrote:
> Probably the best idea is to backup the last WAL file for each timeline
> seen. Keep track of that, so when the current file changes you'll know
> which timeline you're on and stick to that from then on. Or more simply,
> put some notes with your program saying "if you ever use a complex
> recovery situation, make sure to clear all archive_status files for
> higher timeline ids before using this program".
Tell me if you think this is the most reasonable way to determine the in use
WAL file:
ls -rt $PGDATA/pg_xlog/ | grep -v "backup\|archive\|RECOVERY" | tail -1
> This would not be necessary had I completed my logswitch patch in time
> for 8.1 freeze, but I regret that I was unable to do that.
What's the logswitch patch going to accomplish? Sounds interesting.
Also, I have an interesting and unrelated question...this past weekend, we had
a failure in which we had to restore from backup. I have created a script
which makes a base backup every two weeks and we keep the last two. Also, we
use PITR for replication, making a base backup between the primary and
secondary server every 8 hours, and running my rsynclastlog script once/minute
to keep as up to date as possible. Now here's the problem...the servers
switched roles on Sep 21. We switched them back a little while after that.
When I went to replay the WAL files using the Sep 15 base backup, it happily
played back the WAL files to Sep 21 and stopped. I presume that this means
whenever the servers switch roles I need to create a fresh base backup?
Is there any possible way to replay the other WAL files after the Sep 21
switchover/switchback? I'm going to guess this is similar to having another
timeline.
We restored from a nightly pg_dump which we have kept doing, but that means we
lost about 20 hrs of data. :-(
--
Jeff Frost, Owner <jeff@frostconsultingllc.com>
Frost Consulting, LLC http://www.frostconsultingllc.com/
Phone: 650-780-7908 FAX: 650-649-1954
