Open Stack

----- Original Message -----
> From: "Jay Pipes" <jaypipes at gmail.com>
> To: "Attila Fazekas" <afazekas at redhat.com>
> Cc: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>, "Pavel
> Kholkin" <pkholkin at mirantis.com>
> Sent: Tuesday, February 10, 2015 7:32:11 PM
> Subject: Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera
> 
> On 02/10/2015 06:28 AM, Attila Fazekas wrote:
> > ----- Original Message -----
> >> From: "Jay Pipes" <jaypipes at gmail.com>
> >> To: "Attila Fazekas" <afazekas at redhat.com>, "OpenStack Development Mailing
> >> List (not for usage questions)"
> >> <openstack-dev at lists.openstack.org>
> >> Cc: "Pavel Kholkin" <pkholkin at mirantis.com>
> >> Sent: Monday, February 9, 2015 7:15:10 PM
> >> Subject: Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody
> >> should know about Galera
> >>
> >> 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.
> >
> > Galere does not replicates the row-level locks created by UPDATE/INSERT ...
> > So what to do with the UPDATE?
> 
> No, Galera replicates the write sets (binary log segments) for
> UPDATE/INSERT/DELETE statements -- the things that actually
> change/add/remove records in DB tables. No locks are replicated, ever.

Galera does not do any replication at UPDATE/INSERT/DELETE time. 

$ mysql
use test;
CREATE TABLE test (id integer PRIMARY KEY AUTO_INCREMENT, data CHAR(64));

$(echo 'use test; BEGIN;'; while true ; do echo 'INSERT INTO test(data) VALUES ("test");'; done )  | mysql

The writer1 is busy, the other nodes did not noticed anything about the above pending
transaction, for them this transaction does not exists as long as you do not call a COMMIT.

Any kind of DML/DQL you issue without a COMMIT does not happened in the other nodes perspective.

Replication happens at COMMIT time if the `write sets` is not empty.

When a transaction wins a voting, the other nodes rollbacks all transaction
which had a local conflicting row lock.


> > Why should I handle the FOR UPDATE differently?
> 
> Because SELECT FOR UPDATE doesn't change any rows, and therefore does
> not trigger any replication event in Galera.

What matters is the full transaction changed any row at COMMIT time or not.
The DMLs them-self does not starts a replication as `SELECT FOR UPDATE` does not.

>
> See here:
> 
> http://www.percona.com/blog/2014/09/11/openstack-users-shed-light-on-percona-xtradb-cluster-deadlock-issues/
> 
> -jay
> 
> >> https://groups.google.com/forum/#!msg/codership-team/Au1jVFKQv8o/QYV_Z_t5YAEJ
> >>
> >> Best,
> >> -jay
> >>
>