"Tang, Jason" <jason.tang at teamuk.telstra.com> writes:
> Ok lets have a go at explaining.
>
> I have to two databases 'provision' and 'order' there are no
> relationships/keys between the two. From your definition of cluster, I
> _think_ I mean that there is cluster called 'foo' and there are two
> slony 'sets' - id = 1 (provision), and id = 2 (order).
>
> Is the right approach?

So "provision" and "order" have nothing in common, including that they
reside in separate databases, right?

If they haven't got anything in common, I'd be somewhat inclined to
have them be two separate Slony-I clusters.

It would be _possible_ to have two sets in one cluster, and that
_could_ have the merit of cutting down slightly on the number of slon
processes.  The latter would happen if you decided to have a database
"provision_order" which subscribed to both sets.  The two
subscriptions could be managed by one slon ==> "one slon saved."

But I'd expect that from a security perspective it would be preferable
for the respective sets of data to never need to meet, that is, that
the "provision" cluster would only do "provision" stuff, and the
"order" cluster would only do "order" stuff.

I'm also reluctant to attach unrelated things together as if any node
is down, that holds back confirmations across the whole cluster.
Which prevents cleaning stuff up.  If something goes "bump" with an
orders node, the tied-together-cluster leads to that affecting
provision nodes.

There isn't a self-evident right or wrong here, but my bias would be
to have two clusters...
-- 
"cbbrowne","@","ca.afilias.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)