Clinging to sanity, louis.gonzales@linuxlouis.net (Louis Gonzales) mumbled into her beard:
> Hey Jim, Thanks again for the pointer to this. I've already
> compiled and installed on one of the two Solaris nodes, that I
> needed to. Yeah upon further reading, I can't wait for Slony-II to
> come out - is there truth behind the "anyday" rumor? - is it also
> true that it's going to implement the true multi-master scenario,
> where updates can be made at any of the clustered nodes.
I'm not holding my breath, at this point.
Performance results have indicated the Slony-II approach wouldn't work
out well for systems where there is heavy competition for locks on
some objects. The trouble is that you wind up having to distribute
locks, and if the application has common heavily-updated objects, the
cost winds up prohibitive...
> I'm going to deploy the "slon worker process" locally on every
> participating node, rather than letting the master host the "slon"
> processes for every cluster participant, for performance reasons.
I run quite a lot of Slony-I nodes, and let me be pointed...
Performance is NOT a good reason (or a reason at all) to spread slon
processes across a bunch of hosts.
Performance of replication is based on the I/O taking place in the
databases; the costs of distributing some of the slon network traffic
will be fairly immaterial.
The "savings" from hosting slons on specific DB nodes is an illusion.
The data will all have to cross the network to get from sources to
providers, so whether the slon is on one host or another, you'll have
the same traffic transmitted around.
Having slons centralized makes it way simpler to manage them; I can't
see there being anywhere near enough benefit from any savings of
network traffic to actually represent a material performance
improvement.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','cbbrowne.com').
http://linuxdatabases.info/info/slony.html
Never criticize anybody until you have walked a mile in their shoes,
because by that time you will be a mile away and have their shoes.
-- email sig, Brian Servis