Re: Slony v. DBMirror

On Thu, May 05, 2005 at 03:35:27PM +0100, Peter Wilson wrote:
> Looking at Slony now, can someone tell me what the benefits of Slony are
> over DBmirror? As far as I can see:
> + both are async Master->multiple slaves
> + both (I think) can do cascaded replication

This isn't really true of dbmirror.  You can do it, but if you lose
the intermediate system, you also lose the cascaded ones (the
downstream one doesn't know about the state of the top-level origin).
Slony is designed to cover that case (it was one of several criteria
we had to satisfy).

> + neither replicate schema changes

This is sort of false, too.  Slony has a facility for injecting the
schema changes at just the right spot in the replication sets, so
that you really can push your schema changes through Slony.  (This
isn't to say you should regularly do this -- it's designed for
production systems, where schema changes should be relatively rare.)

> + nether do automatic switch-over

Any async replication system which routinely does automatic _fail_
over is, in my opinion, a product not suited for production.  This is
a decision that generally needs to be made at Layer 9 or so -- when
you kill a data source, you are potentially walking away from data.
(Naturally, some special cases will call for such fail over anyway.
It's possible to set up Slony for this, of course, just dangerous.
You'd need some external scripts, but they're not impossible to
build.  There's been a recent discussion of this topic on the slony
lists.)  Slony _does_ have pretty good facilities for controlled
switch over (as well as a good mechanism for fail over, where you
abandon the old origin).  With the right arrangements with pgpool,
you ought to be able to do a controlled switch over of a data origin
without a client outage.  This is part of the system by design.  That
design turns out to be harder than you'd think.

Slony also replicates sequences, has extensive guards against data
loss, and can deal with triggers that need to be working or not
depending on the current use of a table in a set.  The data loss
problem due to unreliable nodes is quite a bit nastier than it might
seem.  The problem isn't just to replicate.  The problem is to
replicate in a provably reliable way.

> All slony seems to offer is a different configuration system and the
> ability to automatically propogate configuration changes. It seems this
> could be added to DBmirror pretty easily so why a whole new project?

We looked at the options when we launched the project, believe me. At
the time, we were using erserver, the development of which we'd also
subsidized (starting in 2001).  We learned a lot from the troubles we
had with that system (some of which were addressed in what is the
current commercial erserver code), and the result was that we
concluded we could not "backport" several of the features we wanted
into either erserver or dbmirror (aside from the
frustrating-but-mostly-works original Java engine in the
first-released community erserver, there isn't much to distinguish
dbmirror and the community erserver).  If you want to see the results
of our investigation, and (by inference) the criteria we used to
decide what would satisfy our requirements, you can see Jan's concept
paper; it's at
<http://developer.postgresql.org/~wieck/slony1/Slony-I-concept.pdf>.

A

--
Andrew Sullivan  | ajs@crankycanuck.ca
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
        --Dennis Ritchie