On 10/17/2012 05:19 PM, Steve Singer wrote:
> After your done your MOVE SET you can issue SUBSCRIBE SET to make any
> other nodes use your new master as a provider.  Then you should be able
> to issue DROP NODE commands to drop the old master.  I don't see why you
> can't take the old nodes out of service after you do a DROP NODE.

OK, I'll try that -- thanks!

> This of course doesn't help you want slony to help you in the case of a
> real failover.  I thought you were trying to test your failover
> scenarios, If people are planning on using slony for failover I
> *strongly* encourage them to test their scripts before hand.

We need to do both. My immediate task is to figure out how to "migrate"
a slony cluster from one set of servers to a new set with minimal
disruption and downtime. Understanding now that they all must be the
same minor version on slony helps. Your tip above about the
move/subscribe helps more if it gets us a reliable process.

But the fact that failover seems so fragile is troubling. If it fails to
failover so often in our "migration" tests, why should we think that it
won't fail to failover when we really need it? Is failover fragile
because we need to STONITH before doing the failover? Would that prevent
these race conditions?

> If your going to move forward with Jan's idea of provisioning a box with
> both slony 2.1.0 and slony 2.1.2 (I am not convinced that the failover
> bug you hit is fixed in 2.1.2/ is #260 ) you will need to put two
> versions of slony on the same machine.  A 2.2 feature we added puts the
> slony version number inside of the slony_funcs.so filename to make this
> work nicely.  We have back-ported this to the 2.1 branch here
> https://github.com/ssinger/slony1-engine/tree/REL_2_1_STABLE_multiversion
> 
> I've built 2.1.1 and 2.1.2 versions from the multiversion branch, these
> should install on the same system as your existing 2.1.0 binaries. I
> also have RPM spec files that allows an install multiple slony versions
> at the same time. Your policies probably also prevent you from deploying
> code on a new machine from a random github branch, so this might not be
> much help.

I'm not sure how much that helps but I appreciate the pointers as we may
ultimately need them :-)

Joe


-- 
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support