List:Replication« Previous MessageNext Message »
From:Johan De Meersman Date:November 10 2010 7:17am
Subject:Re: Table Locking
View as plain text  
On Tue, Nov 9, 2010 at 7:19 PM, Tears ! <unix.co@stripped> wrote:

> The problem here is that during step 1 and step 3 we do not want other
> servers to query for any existing locks to avoid duplicate locks. Since our
> two db servers are running in a master-master configuration on a shared IP
> with heatbeat so it might happen that web1 locks a db table on db1 and web2
> ends up querying db2. That's why we want a table to be locked on both db
> servers.
>

Aha, that's where your problem is, alright. As you're finding, it's not a
good idea to do writes on both masters at once, excactly because of locking
and concurrency issues.

Given that you're also implying a loadbalancing scenario, I assume you're
also running ldirectord with your heartbeat and ipfail ? I
*strongly*recommend you add another virtual IP that you use
specifically for write
operations, and only ever assign that to a single master - that'll neatly
avoid you the asynchronicity issues you're having. Ipfail will then switch
that IP over to the other master if the "primary" fails.





-- 
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel

Thread
Table LockingTears !8 Nov
  • Re: Table LockingMats Kindahl8 Nov
    • Re: Table LockingJohan De Meersman8 Nov
      • Re: Table LockingMats Kindahl8 Nov
        • Re: Table LockingJohan De Meersman9 Nov
    • Re: Table LockingTears !9 Nov
      • Re: Table LockingJustin Edwards9 Nov
        • Re: Table LockingRick James9 Nov
      • Re: Table LockingMats Kindahl9 Nov
      • Re: Table LockingJohan De Meersman10 Nov
        • Re: Table LockingMarcus Bointon10 Nov