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@xxxxxxxxxxxxxxx This work was visionary and imaginative, and goes to show that visionary and imaginative work need not end up well. --Dennis Ritchie ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@xxxxxxxxxxxxxx
