Re: Slony v. DBMirror - Mailing list pgsql-general

Andrew Sullivan wrote:
> 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).

That's true. The alternative is to simply replicate from master to both
slaves, but this places an additional load on the master.
>
>
>>+ 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.)
>
I got the lack of schema changes from the Slony documentation. I guess
there must be some manual intervention though to say 'make these schema
chagnes now'?

>
>>+ 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.

That wasn't meant to be a critisism of either :-)

> (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.

FYI DBmirror with Postgres version 8 also replicates sequences.

>
>
>>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
>

Fair enough - thanks Andrew. When I get some less busy time I'll have
another got with Slony - you've made a good case for it, even though I
probably don't need it for my applications right now (not running a
domanin name registry!). It would probably ease my admin overhead when
things do go wrong though which is good.

thanks
Pete