Ivan Zolotukhin wrote:
> Hello,
>
>> > Third idea:
>> > I install the Slony-I, linux-ha and postgresql on the same server of
>> > the two 2U servers. The web application access to the db server
>> > directly and without pgpool.
>
> AFAIK, Slony does not have failover capabilities you need in HA solution:
>
> http://gborg.postgresql.org/project/slony1/genpage.php?howto_overview
>
> So you will need pgpool layer (or some other connection manager +
> network monitoring software) to detect failures anyway.
>
I believe the HA scripts would need to call the appropriate slonik
scripts to cause the failover to occur "properly" (calling the slonik
failover command). I think this is a viable option - albeit dangerous
(since some committed transactions might be lost). Normally, you'd also
have the HA script take over the IP of the master as well, but if you
used pgpool (in master/slave mode) then you could have it tell pgpool to
make the switchover for you. Keep in mind that if you ran a separate
pgpool server you'd want to ensure that it had a backup as well.
pgpool is nice, since when a master fails, the changes aren't lost on
the slave. However, AFAIK getting to the starting point (where both
servers are identical) would require the cluster to be down for a bit.
Slony-I does a much better job of this in that it performs the
replication itself (it will bring the slave up to a consistent state
automagically). However, that can be a time consuming task, depending
on how much data you have.
Just a thought, but I think it should be possible to use Slony-I to
bring a master and slave up to a consistent state, then perform a 'lock
set' then a 'wait for event' (to ensure both nodes are consistent), then
a disable of slony-I (so both nodes are writeable) then switch from
pgpool degeneration mode to replication mode. I think this would give
you the best of both worlds - pgpool without the startup downtime,
synchronous replication, etc. You'd have a "recovery period" where
Slony-I sync'd things up... You'd still have some of the pgpool
shortcomings (most notably things like 'select nexval()' type statements
and lack of secure authentication...but wouldn't suffer from data loss
in the case of a failure.
--
Chander Ganesan
Open Technology Group, Inc.
One Copley Parkway, Suite 210
Morrisville, NC 27560
Phone: 877-258-8987/919-463-0999
http://www.otg-nc.com
