Peter Wilson wrote:
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.
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.)
This is what you'd want to look at for schema changes: http://gborg.postgresql.org/project/slony1/genpage.php?slonik_commands#stmt_ddl_script
You want to be absolutly, 100% sure that the schema changes are going to work on all nodes before firing them through this, because you only get one shot. The accepted best practice for doing this is to put the schema changes in a transacation block that rolls back, and run them via psql against all the nodes, and make sure nothing breaks.
--
Brad Nicholson 416-673-4106 Database Administrator, Afilias Canada Corp.
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
