On 1/5/2005 8:03 AM, David Darville wrote:
> On Mon, Jan 03, 2005 at 07:54:15PM -0500, cbbrowne at ca.afilias.info wrote:
>> > I'm testing a 3 node Slony-I cluster, and it replicates without problems,
>> > until I try to do a switchover as described in slony-I-failover.txt, by
>> > using the following slonik commands:
>> >
>> > lock set (id = 1, origin = 2);
>> > wait for event (origin = 2, confirmed = 1);
>> > move set (id = 1, old origin = 2, new origin = 1);
>> > wait for event (origin = 2, confirmed = 1);
> 
>> OK, so can I make a few assumptions and see if they're right?
>> 
>> --> I assume that you didn't see any manifest errors in the process of
>> moving the set origin.
>> 
>> --> I assume that you're seeing activity go thru fine between nodes 1 and
>> 2, and you're simply not seeing _anything_ happen on node 3.  It sorta
>> looks like node 3 is OK; it just isn't getting updated, right?
>> 
>> If those are all good assumptions, then the problem is almost certainly
>> that you have a broken/inadequate set of "listen paths."  They're in table
>> sl_listen, set up by the STORE LISTEN command.
>> 
>> This is listed in the FAQ; you can see a description of a similar scenario
>> here:
>> <http://linuxdatabases.info/info/faq.html#AEN41038>
> 
> I ended up creating all possible listen path's (receiver != provider), and now
> it works.
> 
> But when moving origin of the set from node 1 to node 2, I end up with
> having node 1 forward all changes to node 3. And what I really need is a way
> to take down node 1 for maintenance, and that I cannot do while it forwards
> to node 3.
> I can only see 2 ways to change that - either I can unsubscribe node 3 and
> subscribe it with node 2 as provider, but that locks down node 3 for quite a
> while, or I could do a failover instead, and risk loosing some data.

If your original config was

     node 1 = origin
     node 2 = subscribed with 1 as provider
     node 3 = subscribed with 1 as provider

a bare "move set" to node 2 only changes this to

     node 1 = subscribed with 2 as provider
     node 2 = origin
     node 3 = subscribed with 1 as provider

So you now have a cascaded setup. What you want to do is to change the 
data provider for node 3, which is not-so-intuitively done by issuing 
another

     subscribe set (id = 1, receiver = 3, provider = 2);

Do not unsubscribe first, just use subscribe set to "change" the 
existing subscrption.


Jan

> 
> --
> David Darville
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #