Open Stack

On 10/02/15 18:29, Jay Pipes wrote:
> On 02/10/2015 09:47 AM, Matthew Booth wrote:
>> On 09/02/15 18:15, Jay Pipes wrote:
>>> On 02/09/2015 01:02 PM, Attila Fazekas wrote:
>>>> I do not see why not to use `FOR UPDATE` even with multi-writer or
>>>> Is the retry/swap way really solves anything here.
>>> <snip>
>>>> Am I missed something ?
>>>
>>> Yes. Galera does not replicate the (internal to InnnoDB) row-level locks
>>> that are needed to support SELECT FOR UPDATE statements across multiple
>>> cluster nodes.
>>>
>>> https://groups.google.com/forum/#!msg/codership-team/Au1jVFKQv8o/QYV_Z_t5YAEJ
>>>
>>
>> Is that the right link, Jay? I'm taking your word on the write-intent
>> locks not being replicated, but that link seems to say the opposite.
> 
> This link is better:
> 
> http://www.percona.com/blog/2014/09/11/openstack-users-shed-light-on-percona-xtradb-cluster-deadlock-issues/
> 
> 
> Specifically the line:
> 
> "The local record lock held by the started transation on pxc1 didn’t
> play any part in replication or certification (replication happens at
> commit time, there was no commit there yet)."

Thanks, Jay, that's a great article.

Based on that, I think I may have misunderstood what you were saying
before. I currently understand that the behaviour of select ... for
update is correct on Galera, it's just not very efficient. Correct in
this case meaning it aborts the transaction due to a correctly detected
lock conflict.

FWIW, that was pretty much my original understanding, but without the
detail.

To expand: Galera doesn't replicate write intent locks, but it turns out
it doesn't have to for correctness. The reason is that the conflict
between a local write intent lock and a remote write, which is
replicated, will always be detected during or before local certification.

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490