"Victoria Parsons" <victoria.parsons at streamshield.com> writes:
> Hi Chris
>
> Thanks for the advice. I have recently moved from using 1.1.0 to 1.1.5,
> and hadn't realised STORE LISTEN was dead (I am using a link to 1.1.0
> docs). In answer to your follow up questions:
>
> I have a complete set of cross paths for all nodes to every other node.
> I set these up as each node is added to the cluster for the purpose of
> having an easy time if I need to move set / failover in the future. 
>
> I also have a complete set of listens, whereby every node listens to
> every other node directly (origin==provider)
>
> Before the move (originally all nodes receive from node 1) the subscribe
> table is as below
>
> sub_set | sub_provider | sub_receiver | sub_forward | sub_active
> ---------+--------------+--------------+-------------+------------
>        1 |            1 |            2 | t           | t
>        1 |            1 |            3 | t           | t
>        1 |            1 |            4 | t           | t
>
>
> After the move set, node 2 accepts data (move commands below)
>
> <preamble>
> Lock set (id=1, origin=1);
> Wait for event (origin=1, confirmed=all);
> Move set (id=1, old origin=1, new origin=2);
> Wait for event (origin=1, confirmed=all);
>
> I am now left with a set that has origin on node 2, but nodes 3 and 4
> are still getting their data via node 1.
>
> sub_set | sub_provider | sub_receiver | sub_forward | sub_active
> ---------+--------------+--------------+-------------+------------
>        1 |            1 |            3 | t           | t
>        1 |            1 |            4 | t           | t
>        1 |            2 |            1 | t           | t
>
> The other change I see is that in sl_listen, two entries have changed. I
> now have: 
> origin=2, provider=1, receiver=3
> origin=2, provider=1, receiver=4
>
> Before the move these lines had provider=2, but were unused I suppose as
> no data came from node 2 at the time.
>
> So I have all the right paths set up, but I cannot change the listens
> directly. What can I do to get nodes 3 and 4 listening/subscribing
> directly to node 2?
>
> My other question is, what do you expect to happen to the subscribe
> table after a move set? From your question 2 it sounds like you don't
> expect node 1 to be a provider any more. Is this a bug?

I wasn't sure how you had things set up, which is why I asked the
question...

I guess I imagined that if you didn't expect node 1 to be
participating in "listening," then it surely couldn't be a provider
anymore.  Evidently, I was wrong, which means that the question about
the subscription shape was definitely appropriate to ask!

Your problem/issue is NOT with sl_listen / listen paths; that is
(properly!) incidental to how the subscriptions are set up.

The MOVE SET does not do a massive reshaping of subscriptions; it may
reverse a number of subscription paths, but won't automatically point
everything away from the node that used to be origin.

Before you can drop out node 1, you'll have to submit SUBSCRIBE SET
requests to point nodes 3 and 4 to "somewhere else."  Presumably you'd
point them to node 2.

Note that submitting SUBSCRIBE SET against a node that is already
subscribing to the requested set doesn't make it start from scratch;
it just reshapes the subscription.

I expect that what you need to do is to submit a slonik script like:
----------------------
include <mycluster.preamble>;
subscribe set (id=1, provider=2, receiver=3);
subscribe set (id=1, provider=2, receiver=4);
----------------------

That will reshape the subscriptions, and, implicitly, reshape
sl_listen somewhat.  There should be rather fewer cases where
sl_listener shows node 1 as an event provider, though it will by no
means disappear until you actually drop node 1.

By the way, dropping the node will require specifying an EVENT NODE...

----------------------
include <mycluster.preamble>;
drop node (id=1, event node=2);
----------------------

Otherwise, as node 1 becomes a "black hole," the message of its
departure (which, without expressly requesting an EVENT NODE, goes to
node 1) may not be able to escape the 'event horizon' :-).
-- 
select 'cbbrowne' || '@' || 'ca.afilias.info';
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)