Open Stack

----- Original Message -----
From: "Attila Fazekas" <afazekas at redhat.com>
To: "Jay Pipes" <jaypipes at gmail.com>
Cc: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>, "Pavel Kholkin" <pkholkin at mirantis.com>
Sent: Thursday, February 12, 2015 11:52:39 AM
Subject: Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera





----- 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: Wednesday, February 11, 2015 9:52:55 PM
> Subject: Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera
> 
> On 02/11/2015 06:34 AM, Attila Fazekas wrote:
> > ----- 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.
> 
> We're going in circles here. I was just pointing out that SELECT ... FOR
> UPDATE will never replicate anything. INSERT/UPDATE/DELETE statements
> will cause a write-set to be replicated (yes, upon COMMIT of the
> containing transaction).
> 
> Please see my repeated statements in this thread and others that the
> compare-and-swap technique is dependent on issuing *separate*
> transactions for each SELECT and UPDATE statement...
> 
> > When a transaction wins a voting, the other nodes rollbacks all transaction
> > which had a local conflicting row lock.
> 
> A SELECT statement in a separate transaction does not ever trigger a
> ROLLBACK, nor will an UPDATE statement that does not match any rows.
> That is IMO how increased throughput is achieved in the compare-and-swap
> technique versus the SELECT FOR UPDATE technique.
> 
yes, I mentioned this way in one bug [0].

But the related changes on the review, actually works as I said [1][2][3],
and the SELECT is not in a separated dedicated transaction.


[0] https://bugs.launchpad.net/neutron/+bug/1410854 [sorry I sent a wrong link before]
[1] https://review.openstack.org/#/c/143837/
[2] https://review.openstack.org/#/c/153558/
[3] https://review.openstack.org/#/c/149261/

> -jay
> 
> -jay
>