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?

Thanks,
Vicki
 

 

-----Original Message-----
From: cbbrowne at ca.afilias.info [mailto:cbbrowne at ca.afilias.info] 
Sent: 05 July 2006 13:16
To: Victoria Parsons
Cc: slony1-general at gborg.postgresql.org
Subject: Re: [Slony1-general] problems after move set


> I did this using
> <slon preamble>
> store listen (origin=2, provider=2, receiver=3);
> store listen (origin=2, provider=2, receiver=4);
>
> This seemed to have no effect at all and I can't see any evidence of
the
> store listen commands being processed.

STORE LISTEN was turned into a NOOP in version 1.1, which is probably a
mistake, albeit well-intentioned.  The paths are calculated based
primarily on what subscriptions you have in place.

The algorithm for calculating the paths in sl_listen changes in 1.2, for
the better but it seems to me that STORE LISTEN should still be
available
even though you'd usually prefer not to use it...

> Is what I am doing correct? Is it possible to now get nodes 3 and 4
> listening directly to node 2, so I can drop node 1 from the
replication
> completely?

Well, do you have paths in sl_path for that?  If you do, then they can
do so.

When you drop node 1, the paths in sl_listen will get reshaped based on
the way things look after the node is gone.

The two followup questions would be:

1.  Are there entries in sl_path for nodes 3+4 to get directly to node
2?

2.  What is the shape of the subscriptions in sl_subscribe?  The thing
that would be a bad thing would be if anything was still being provided
data by node 1.

You can't drop node 1 until any subscribers that go to node 1 are
redirected to some other provider.



This message should be regarded as confidential. If you have received this 
email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy 
by an authorized signatory.