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