On Wednesday 03 June 2009 15:26, Greg Smith wrote:
> On Wed, 3 Jun 2009, Geoffrey wrote:
> > 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 are three things to setup here:
>
> 1) archive_command on the master
> 2) Transport between master and standby(s)
> 3) recovery_command. pg_standby is the reference implementation here.
>
> You can combine (1) and (2) by putting some sort of network copy command
> into the archive_command, but better practice here (and probably required
> practice in your case) is to write a script that does that instead.
> That's the part you need to worry about.
>
> There is no need for you to reinvent (3) just because you have different
> requirements than most for (2). As you've noticed, pg_standby doesn't
> actually do the network transport part, and that also means that it's
> decoupled from what choices you make for that layer. Focus on writing
> scripts to atomically copy the files into the right destination on the
> standbys, and pg_standby will take care of applying the shipped log files
> to the database.
>
> --
> * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Our circumstance here is that we will be feeding multiple warm stand-by
servers; one local and the rest remote, that is, at least one in other state
and possibly another in another city. We didn't want the WAL shipping process
to fail because one of the nodes might be down. To circumvent that, we
thought the best approach to take was to pump the WAL logs to a central
machine on-site, and have the warm stand-by servers pick up their files from
the central storage device. This is why we were thinking about changing
pg_standby.
Thanks for all the help...
--
Work: 1-336-372-6812
Cell: 1-336-404-6987
email: terry@chosen-ones.org