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.
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'?
+ 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.
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
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@xxxxxxxxxxxxxx)
