----- Original Message -----
> From: "Jay Pipes" <jaypi...@gmail.com>
> To: "Attila Fazekas" <afaze...@redhat.com>
> Cc: "OpenStack Development Mailing List (not for usage questions)"
> <email@example.com>, "Pavel
> Kholkin" <pkhol...@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" <jaypi...@gmail.com>
> >> To: "Attila Fazekas" <afaze...@redhat.com>, "OpenStack Development Mailing
> >> List (not for usage questions)"
> >> <firstname.lastname@example.org>
> >> Cc: "Pavel Kholkin" <pkhol...@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.
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
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
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
> See here:
> >> https://groups.google.com/forum/#!msg/codership-team/Au1jVFKQv8o/QYV_Z_t5YAEJ
> >> Best,
> >> -jay
OpenStack Development Mailing List (not for usage questions)