Note: I've removed -general, since this is really just a Slony discussion.
On Thu, Dec 27, 2007 at 12:49:55PM -0500, Josh Harrison wrote:
> We wanted to have 1 master and 1 slave that can be queried and 1 warm
> standby server that can be brought up in case of crash. So I thought it
> might be better to have WAL shipping for warm standby since thats working
> pretty good and Slony for master-slave replication.
> Let me know your comments on this setup? What is better for this setup?
The disadvantage of that approach is that you have two different systems you
have to maintain. You could maintain more than one Slony replica, which
would have the advantage of flexibility. For instance, you could have two
replicas, and in the event your origin failed, you just move the origin to
one of the replicas. If one of your replicas failed, however, you could
use the other replica for whatever thing the failed-replica was doing (so
your "query-only" system could also be your standby while you repaired the
other standby).
In general, I think the best arrangement is the least complicated one. Two
different replication strategies in the same mix seems to me to be the sort
of complication that will make emergency recovery harder. OTOH, two
different strategies presumably protects you from bugs in the other code.
(For instance, a DNS company runs completely different name server code on
completely different hardware and OS platforms in order to make sure not to
be vulnerable to day-0 exploits. That kind of thing.)
> That will be very useful since our people are debating on the reliability of
> Slony for large databases!!!
The size of the database is not the determining factor in Slony reliability.
What is the change rate on your systems? That's the big factor in any
replication system, really. Afilias's systems are quite active -- there's a
_lot_ of churn on top level domains these days.
A
