----- Original Message -----
> From: "Jay Pipes" <[email protected]>
> To: "Attila Fazekas" <[email protected]>
> Cc: "OpenStack Development Mailing List (not for usage questions)"
> <[email protected]>, "Pavel
> Kholkin" <[email protected]>
> 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" <[email protected]>
> >> To: "Attila Fazekas" <[email protected]>, "OpenStack Development Mailing
> >> List (not for usage questions)"
> >> <[email protected]>
> >> Cc: "Pavel Kholkin" <[email protected]>
> >> 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
> >>
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
