Open Stack

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.

-jay

-jay