Assume we have a primary database server and a warm
standby. WAL files get shipped over to the standby and
applied as they arrive.
Questions:
1. I know the recommendation is to fail over to the
standby and re-configure the primary as a new standby.
Is it possible to do that without any data loss? I
know I can copy un-archived WAL files to the archive
area, but is that guaranteed not to result in any data
loss? I suppose that would require turning on the
option that forces a sync of the WAL file before
finishing a transaction. I guess I'm asking as to the
recommended procedure that minimizes data loss /
outage window when purposely failing over to the
standby.
2. How would you deal with archiving the new master DB
server? Should there be a second WAL archive area? If
you copied un-archived WAL files, and the DB server
tries to archive them - you're going to have a
problem. The documentation says that the archive
script should not overwrite files silently. Can those
un-archived WAL files be copied to the pg_xlog
directory directly? Will postgresql look in there
first before activating the restore_command?
3. If you want to have an automatic failover to the
standby - does that mean that your standby needs to
archive WAL files as well? Otherwise you'd have a
window where the current primary is not doing any
archiving. OR you'd have 2 archive copies of your WAL
files.
Mostly I'm looking for input from people who are
running warm standby in production environment,
especially with respect to any gotchas. I did manage
to successfully setup a standby server and I am able
to fail over to it. I found the messages on this list
that recommend failing over periodically, and I am
wondering if people are accepting data loss for what
should be a maintenance event.
Thanks in advance for any input. As I mentioned
before, I believe I have the base case covered. Just
trying to play with a bit of *what if*.
Greg
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
