On 02/11/2015 06:34 AM, Attila Fazekas wrote:
----- Original Message -----
From: "Jay Pipes" <jaypi...@gmail.com>
To: "Attila Fazekas" <afaze...@redhat.com>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>, "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)"
<openstack-dev@lists.openstack.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.

$ 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

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to