On 02/11/2015 06:34 AM, Attila Fazekas wrote:
----- 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.
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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
