On Tue, Nov 27, 2012 at 8:59 AM, Frank McGeough <
Frank.Mcgeough at vocalocity.com> wrote:

>  I'm writing to ask about using Slony switchover capability. I've never
> actually been able to make this work. I'm curious about whether this is a
> common experience or if, perhaps, there is something that I don't
> understand about how this should function. The environment that I have is a
> database that is in constant use. That is, there is always at least a low
> level of DML (inserts for the most part) occurring 24 x 7, 365 days a year.
> I've found that Slony will never be able to get a lock in order to perform
> the switchover and thus I'm left with tearing replication completely down
> and rebuilding from scratch if I have to perform maintenance on the
> primary. Do people find this unusual or is this somewhat expected — and the
> only time this actually functions as described in the documentation is if
> you are able to shutdown all database operations for a short period of time
> ( a few seconds even)?
>
>  What I do currently is use a VIP (
> http://en.wikipedia.org/wiki/Virtual_IP_address ) to control how the
> various app servers are connecting to the primary database. I modify this
> to go to what was the slave, stop the slony processes, drop the slony
> schema and then restart replication from scratch.
>
>
Slony is designed to do exactly what you are stating it's not able to. We
run a very busy site and switchover's "albeit one of those moments where
you hold your breath", work without an issue (knocks on wood). We too use a
virtual for our insert DB's and Query db's (inserts are the master/slave) .
As part of the switchover we hit the switchover button (script) and at
about the same time, we move the slave into the vip. We have 3 sets that
have to move, but 99.9% of the time the switchover works without a hitch
(the .1% is when we have done changes, or schema modifications or other and
didn't clean up after ourselves properly).

So this works and has worked for many many versions now.

Not sure why it can't get a lock, at some point it's request has to take
priority over a later request.

Tory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20121129/3601dcf9/attachment.htm