Joshua D. Drake wrote:
On Wed, 2009-06-03 at 14:43 -0400, Geoffrey wrote:
pg_standby is in no way dependent on PITRTools. PITRTools is, however,
dependent on pg_standby. Put another way: you do not need to use
PITRTools to use pg_standby. In fact, you also don't need any perl or
shell scripts to use pg_standby, just use rsync directly in the
archive_command on the master and pg_standby in the recovery_command on
the standby. The wiki link Greg provided
(http://wiki.postgresql.org/wiki/Warm_Standby) has all of the info
needed to set things up manually.
Our current scenario is that we are archiving from machine A to machine
B. Our hot spare is machine C, thus we are pulling the files via
network from machine B to machine C, hence the reason I don't believe
db_standby will work as it has no facility (rsync,scp) to retrieve the
files from another machine.
The point that is being made is that pg_standby doesn't need pitrtools
to do its job. That is all. It is also why I said that pg_standby is
just a component of a PITR solution and not a PITR Solution in itself.
I understand his point very clearly.
You are still going to need to either:
A. Reinvent the wheel, by scripting it all yourself
B. Use solutions that are already used by others such as walmgr or
pitrtools
My assumption was that since pg_standby does not have the scp/rsync
functionality, I would have to either modify it, change the way we do
things, or 'reinvent' a little different wheel.
There is also an objection to using the python tools as we are small
shop and do not have anyone who is versed in python.
I have not had a chance to look at walmgr, I will do that shortly.
--
Until later, Geoffrey
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
