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 ! <> 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

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