On 12-11-27 11:59 AM, Frank McGeough 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

The slony MOVE SET operation needs to have an exclusive lock on all 
tables in the set at the same time.   The recommended way of doing this 
is to have your application stop traffic to the database for long enough 
so that this can be done, and then wait for the event to propogate to 
the new master and then have your application start queries against the 
new master.

If slony gets its locks on a move set in this order
Table1
Table2
Table3

but your application access tables in this order
Table3
Table2
Table1

Your application and slony will deadlock each other.



> 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.
>
>
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
>