: Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody
should know about Galera
- 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
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 jaypi...@gmail.com
To: Attila Fazekas afaze...@redhat.com
Cc: OpenStack Development Mailing List
: 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
On 02/11/2015 07:58 AM, Matthew Booth wrote:
On 10/02/15 18:29, Jay Pipes wrote:
On 02/10/2015 09:47 AM, Matthew Booth wrote:
On 09/02/15 18:15, Jay Pipes wrote:
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
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
On 10/02/15 18:29, Jay Pipes wrote:
On 02/10/2015 09:47 AM, Matthew Booth wrote:
On 09/02/15 18:15, Jay Pipes wrote:
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
On 09/02/15 18:15, Jay Pipes wrote:
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)
- Original Message -
From: Jay Pipes jaypi...@gmail.com
To: openstack-dev@lists.openstack.org
Sent: Monday, February 9, 2015 9:36:45 PM
Subject: Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody
should know about Galera
On 02/09/2015 03:10 PM, Clint Byrum wrote
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
: 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
On 02/10/2015 09:47 AM, Matthew Booth wrote:
On 09/02/15 18:15, Jay Pipes wrote:
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
- Original Message -
From: Jay Pipes jaypi...@gmail.com
To: openstack-dev@lists.openstack.org, Pavel Kholkin pkhol...@mirantis.com
Sent: Wednesday, February 4, 2015 8:04: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
On 02/09/2015 03:10 PM, Clint Byrum wrote:
Excerpts from Jay Pipes's message of 2015-02-09 10:15:10 -0800:
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
Excerpts from Jay Pipes's message of 2015-02-09 12:36:45 -0800:
CAS is preferred because it is measurably faster and more
obstruction-free than SELECT FOR UPDATE. A colleague of mine is almost
ready to publish documentation showing a benchmark of this that shows
nearly a 100% decrease in
Excerpts from Jay Pipes's message of 2015-02-09 10:15:10 -0800:
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
On 02/09/2015 05:02 PM, Clint Byrum wrote:
Excerpts from Jay Pipes's message of 2015-02-09 12:36:45 -0800:
CAS is preferred because it is measurably faster and more
obstruction-free than SELECT FOR UPDATE. A colleague of mine is almost
ready to publish documentation showing a benchmark of this
Hi Angus,
If causal reads is set in a session, it won't delay all reads, just
that specific read that you set if for. Let's say you have 4 sessions,
in one of them you set causal reads, the other 3 won't wait on
anything. The read in the one session that you set this in will be
delayed, in the
Thanks for the additional details Peter. This confirms the parts I'd
deduced from the docs I could find, and is useful knowledge.
On Sat Feb 07 2015 at 2:24:23 AM Peter Boros peter.bo...@percona.com
wrote:
- Like many others said it before me, consistent reads can be achieved
with
Hi Angus and everyone,
I would like to reply for a couple of things:
- The behavior of overlapping transactions is dependent on the
transaction isolation level, even in the case of the single server,
for any database. This was pointed out by others earlier as well.
- The deadlock error from
On 5 February 2015 at 23:07, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Avishay Traeger's message of 2015-02-04 22:19:53 -0800:
On Wed, Feb 4, 2015 at 11:00 PM, Robert Collins
robe...@robertcollins.net
wrote:
On 5 February 2015 at 10:24, Joshua Harlow harlo...@outlook.com
- Original Message -
From: Matthew Booth mbo...@redhat.com
To: openstack-dev@lists.openstack.org
Sent: Thursday, February 5, 2015 12:32:33 PM
Subject: Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody
should know about Galera
On 05/02/15 11:01, Attila Fazekas
On 04/02/15 19:04, Jay Pipes wrote:
On 02/04/2015 12:05 PM, Sahid Orentino Ferdjaoui wrote:
On Wed, Feb 04, 2015 at 04:30:32PM +, Matthew Booth wrote:
I've spent a few hours today reading about Galera, a clustering solution
for MySQL. Galera provides multi-master 'virtually synchronous'
On 05/02/15 11:11, Sahid Orentino Ferdjaoui wrote:
I'm still confused as to how this code got there, though. We shouldn't
be hitting Galera lock contention (reported as deadlocks) if we're using
a single master, which I thought we were. Does this mean either:
I guess we can hit a lock
Excerpts from Angus Lees's message of 2015-02-04 16:59:31 -0800:
On Thu Feb 05 2015 at 9:02:49 AM Robert Collins robe...@robertcollins.net
wrote:
On 5 February 2015 at 10:24, Joshua Harlow harlo...@outlook.com wrote:
How interesting,
Why are people using galera if it behaves like
Excerpts from Avishay Traeger's message of 2015-02-04 22:19:53 -0800:
On Wed, Feb 4, 2015 at 11:00 PM, Robert Collins robe...@robertcollins.net
wrote:
On 5 February 2015 at 10:24, Joshua Harlow harlo...@outlook.com wrote:
How interesting,
Why are people using galera if it behaves
...@redhat.com
To: openstack-dev@lists.openstack.org
Sent: Thursday, February 5, 2015 10:36:55 AM
Subject: Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody
should know about Galera
On 04/02/15 17:05, Sahid Orentino Ferdjaoui wrote:
* Commit will fail if there is a replication
On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum cl...@fewbar.com wrote:
In a single thread, using a single database session, then a read after
successful commit is guaranteed to read a version of the database
that existed after that commit.
Ah, I'm relieved to hear this clarification - thanks.
Angus Lees wrote:
On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum cl...@fewbar.com
mailto:cl...@fewbar.com wrote:
In a single thread, using a single database session, then a read after
successful commit is guaranteed to read a version of the database
that existed after that commit.
Excerpts from Joshua Harlow's message of 2015-02-06 01:26:25 +:
Angus Lees wrote:
On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum cl...@fewbar.com
mailto:cl...@fewbar.com wrote:
I'd also like to see consideration given to systems that handle
distributed consistency in a more
On Thu, Feb 05, 2015 at 09:56:21AM +, Matthew Booth wrote:
On 04/02/15 19:04, Jay Pipes wrote:
On 02/04/2015 12:05 PM, Sahid Orentino Ferdjaoui wrote:
On Wed, Feb 04, 2015 at 04:30:32PM +, Matthew Booth wrote:
I've spent a few hours today reading about Galera, a clustering solution
On 05/02/15 04:30, Mike Bayer wrote:
Galera doesn't change anything here. I'm really not sure what the
fuss is about, frankly.
because we’re trying to get Galera to actually work as a load
balanced cluster to some degree, at least for reads.
Yeah, the use case of concern here is consecutive
][oslo.db][nova] TL; DR Things everybody
should know about Galera
On 04/02/15 17:05, Sahid Orentino Ferdjaoui wrote:
* Commit will fail if there is a replication conflict
foo is a table with a single field, which is its primary key.
A: start transaction;
B: start transaction;
A: insert
On 05/02/15 11:01, Attila Fazekas wrote:
I have a question related to deadlock handling as well.
Why the DBDeadlock exception is not caught generally for all api/rpc request ?
The mysql recommendation regarding to Deadlocks [1]:
Normally, you must write your applications so that they are
On 04/02/15 17:05, Sahid Orentino Ferdjaoui wrote:
* Commit will fail if there is a replication conflict
foo is a table with a single field, which is its primary key.
A: start transaction;
B: start transaction;
A: insert into foo values(1);
B: insert into foo values(1); -- 'regular' DB
On Fri Feb 06 2015 at 12:59:13 PM Gregory Haynes g...@greghaynes.net
wrote:
Excerpts from Joshua Harlow's message of 2015-02-06 01:26:25 +:
Angus Lees wrote:
On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum cl...@fewbar.com
mailto:cl...@fewbar.com wrote:
I'd also like to see
Excerpts from Angus Lees's message of 2015-02-06 02:36:32 +:
On Fri Feb 06 2015 at 12:59:13 PM Gregory Haynes g...@greghaynes.net
wrote:
Excerpts from Joshua Harlow's message of 2015-02-06 01:26:25 +:
Angus Lees wrote:
On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum
On 2015-02-05 9:36 PM, Angus Lees wrote:
On Fri Feb 06 2015 at 12:59:13 PM Gregory Haynes g...@greghaynes.net
mailto:g...@greghaynes.net wrote:
Along those lines and in an effort to be a bit less doom-and-gloom, I
spent my lunch break trying to find non-marketing documentation on the
Galera
Hey now you forgot a site in that list ;-)
-Josh
Clint Byrum wrote:
You may want to have a chat with the people running MySQL at
Google, Facebook, and a long tail of not quite as big sites but still
massively bigger than most clouds.
I've spent a few hours today reading about Galera, a clustering solution
for MySQL. Galera provides multi-master 'virtually synchronous'
replication between multiple mysql nodes. i.e. I can create a cluster of
3 mysql dbs and read and write from any of them with certain consistency
guarantees.
I
On Wed, Feb 04, 2015 at 04:30:32PM +, Matthew Booth wrote:
I've spent a few hours today reading about Galera, a clustering solution
for MySQL. Galera provides multi-master 'virtually synchronous'
replication between multiple mysql nodes. i.e. I can create a cluster of
3 mysql dbs and read
Matthew Booth mbo...@redhat.com wrote:
This means that even for 'synchronous' slaves, if a client makes an RPC
call which writes a row to write master A, then another RPC call which
expects to read that row from synchronous slave node B, there's no
default guarantee that it'll be there.
On 02/04/2015 12:05 PM, Sahid Orentino Ferdjaoui wrote:
On Wed, Feb 04, 2015 at 04:30:32PM +, Matthew Booth wrote:
I've spent a few hours today reading about Galera, a clustering solution
for MySQL. Galera provides multi-master 'virtually synchronous'
replication between multiple mysql
Matthew Booth mbo...@redhat.com wrote:
A: start transaction;
B: start transaction;
A: insert into foo values(1);
B: insert into foo values(1); -- 'regular' DB would block here, and
report an error on A's commit
A: commit; -- success
B: commit; -- KABOOM
Excerpts from Matthew Booth's message of 2015-02-04 08:30:32 -0800:
* Write followed by read on a different node can return stale data
During a commit, Galera replicates a transaction out to all other db
nodes. Due to its design, Galera knows these transactions will be
successfully committed
How interesting,
Why are people using galera if it behaves like this? :-/
Are the people that are using it know/aware that this happens? :-/
Scary
Mike Bayer wrote:
Matthew Boothmbo...@redhat.com wrote:
A: start transaction;
A: insert into foo values(1)
A: commit;
B: select * from
Excerpts from Joshua Harlow's message of 2015-02-04 13:24:20 -0800:
How interesting,
Why are people using galera if it behaves like this? :-/
Note that any true MVCC database will roll back transactions on
conflicts. One must always have a deadlock detection algorithm of
some kind.
Galera
On 5 February 2015 at 10:24, Joshua Harlow harlo...@outlook.com wrote:
How interesting,
Why are people using galera if it behaves like this? :-/
Because its actually fairly normal. In fact its an instance of point 7
on https://wiki.openstack.org/wiki/BasicDesignTenets - one of our
oldest wiki
Matthew Booth mbo...@redhat.com wrote:
A: start transaction;
A: insert into foo values(1)
A: commit;
B: select * from foo; -- May not contain the value we inserted above[3]
I’ve confirmed in my own testing that this is accurate. the
wsrep_causal_reads flag does resolve this, and it is
On 02/04/2015 07:59 PM, Angus Lees wrote:
On Thu Feb 05 2015 at 9:02:49 AM Robert Collins
robe...@robertcollins.net mailto:robe...@robertcollins.net wrote:
On 5 February 2015 at 10:24, Joshua Harlow harlo...@outlook.com
mailto:harlo...@outlook.com wrote:
How interesting,
On Wed, Feb 4, 2015 at 11:00 PM, Robert Collins robe...@robertcollins.net
wrote:
On 5 February 2015 at 10:24, Joshua Harlow harlo...@outlook.com wrote:
How interesting,
Why are people using galera if it behaves like this? :-/
Because its actually fairly normal. In fact its an instance of
On Thu Feb 05 2015 at 9:02:49 AM Robert Collins robe...@robertcollins.net
wrote:
On 5 February 2015 at 10:24, Joshua Harlow harlo...@outlook.com wrote:
How interesting,
Why are people using galera if it behaves like this? :-/
Because its actually fairly normal. In fact its an instance of
Jay Pipes jaypi...@gmail.com wrote:
No, this is not correct. There is nothing different about Galera here versus
any asynchronously replicated database. A single thread, issuing statements
in two entirely *separate sessions*, load-balanced across an entire set of
database cluster nodes,
53 matches
Mail list logo
