In response to Jerry Sievers <jerry at jerrysievers.com>:

> Bill Moran <wmoran at collaborativefusion.com> writes:
> 
> > In response to Jerry Sievers <jerry at jerrysievers.com>:
> > 
> > > Slony 1.1.5
> > > 
> > > Assuming a cascaded cluster of 3 nodes arranged as follows;
> > > 
> > > Master
> > >         Slave1
> > >                 Slave2
> > > 
> > > If the middle tier Slave1 is totally lost, is there a way to get
> > > Slave2 pointing to Master without data loss, or at all?
> > > 
> > > I am unable to do it with Slonik but had thought this was workable. 
> > 
> > What, exactly, did you try to do?
> > 
> > You should be able to do it by simply issuing a new subscribe set ()
> > command with the correct parameters to subscribe it to Master.
> 
> That was my assumption and I guess also believe that Slonik would feed
> the new subscription info directly to the now cut=-off slave. .  This
> does not seem to be the case.
> 
> original subscription looked like 
> 
> set 1,
> provider 2,
> receiver 3
> 
> New subscription;
> 
> set 1,
> provider 1, 
> receiver 3
> 
> But with the node that was in the middle feeding slave 2 down, I think
> there's no way slave 2 ever hears of the new subscription and it keeps
> trying to connect to the slave that used to be feeding it.
> 
> I've queried the sl_* tables on the  node that I want to reposition
> and see that nothing is  changing.
> 
> Any ideas?

This may come across harsh.  I hope not, but I fear that there's no way
to describe this without sounding harsh.

If you tell us _what_you_did_ instead of _describing_what_you_think_
you_did_, it's much more likely that people on the list will be able
to help.

This is a common problem.  Lots of people say, "I entered the correct
commands", but refuse (for some unknown reason) to simply cut/paste
the commands into their email.

Unfortunately, this strategy comes up against the fact that 99% of the
problems that people have are operator error, and usually boil down to
a very specific misuse of a command.  Without knowing exactly what those
commands are, we'll never find the problem.

That being said, I'm not sure that this is _supposed_ to work.  It' may
be necessary to "DROP NODE" of node 2 in order for Slony to understand
that it's no longer participating.  Haven't tried this personally, but
Slony should automatically reshape paths when node 2 is officially removed.

Of course, someone who knows better may correct me on this.

-- 
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran at collaborativefusion.com
Phone: 412-422-3463x4023