"Sean Kirkpatrick" <Sean.Kirkpatrick at PipelineTrading.com> writes:
> I would think that the different listen paths provide better
> distribution of the data given the node configuration.  As an
> example situation, suppose node 1 suffers a critical failure.  Node
> 2 (or node 3) can be promoted and the cascading configuration of
> node 5 will continue because the listen path is set to receive data
> from node 2 through node 3.  Is that correct?

Well, if you do a MOVE SET, _all_ of the listen paths would get
revised; likewise, a FAILOVER revises all listen paths.

> The only one that seems off is the following:
>
> store listen (origin = 5, receiver = 4, provider = 3);  # 2 is 'optimal'
>
> I think this path should have kept node 2 as the provider...(my
> script is currently generating these listen paths also)

The 'oversimplification' that takes place is that when node 5 is
introduced, as a subscriber to node 3, the heuristic imagines that
node 3 will be the "provider" for everyone listening for node 5 events
(except for node 3, which goes straight to 5).

I agree that node 2 is "optimal," but I'm prepared to live with
suboptimality if the heuristic happens to be "good enough."

The heuristic is simple, and can be applied automatically instead of
requiring an administrator to go off and do some static calculation.

Furthermore, if there are multiple replication sets in a Slony-I
cluster, with different nodes being subscribers/providers for the
different sets, the notion that there is an "optimum" goes out the
window.  For that reason, I'm not "wedded" to the need to have the
provable "optimum."

> I'm in the process of implementing a utility based on the altperl
> scripts to centralize their functionality for our operations group.
> Part of the tool involves initializing the cluster based on a
> configuration file (for initial slony rollout), as well as
> adding/removing nodes, sets, sequences, subscriptions and performing
> failover / switchover.  I've only implemented about 15% of these
> features, but any additional "gotchas" suffered by others (in terms
> of node configurations) will go a long way towards preventing
> replication problems.
>
> How would you recommend working out the listen paths when adding a
> node to an existing configuration?  Query the sl_listen table for
> the current paths?

Neat thing: You merely have to add in the new ones for the new node.
The new ones don't affect the old ones.

So you could pretty much just re-run init_cluster.pl, and "egrep" for
all listens that point to the newly added node(s).
-- 
"cbbrowne","@","ca.afilias.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)