[openstack-dev] [nova][neutron][mysql] IMPORTANT: MySQL Galera does *not* support SELECT ... FOR UPDATE

Amrith Kumar amrith at tesora.com
Thu May 29 18:51:20 UTC 2014


So as another of the panelists on this panel that Jay organized some
comments on Julien's reply below.

| On Mon, May 19 2014, Jay Pipes wrote:
| 
| > I think at that point I mentioned that there were a number of places
| > that were using the SELECT ... FOR UPDATE construct in Nova (in
| > SQLAlchemy, it's the with_lockmode('update') modification of the query
| > object). Peter promptly said that was a problem. MySQL Galera does not
| support SELECT ...
| > FOR UPDATE, since it has no concept of cross-node locking of records
| > and results are non-deterministic.
| 
| So you send a command that's not supported and the whole software
| deadlocks? Is there a bug number about that or something? I cannot
| understand how this can be possible and considered as something normal
| (that's the feeling I have reading your mail, I may be wrong).

[amrith] It keeps on chugging, doesn't stop. 

| 
| > We have a number of options:
| >
| > 1) Stop using MySQL Galera for databases of projects that contain
| > with_lockmode('update')
| >
| > 2) Put a big old warning in the docs somewhere about the problem of
| > potential deadlocks or odd behaviour with Galera in these projects
| >
| > 3) For Nova and Neutron, remove the use of with_lockmode('update') and
| > instead use a coarse-grained file lock or a distributed lock manager
| > for those areas where we need deterministic reads or quiescence.
| >
| > 4) For the Nova db quota driver, refactor the driver to either use a
| > non-locking method for reservation and quota queries or move the
| > driver out into its own projects (or use something like Climate and
| > make sure that Climate uses a non-blocking algorithm for those
| > queries...)
| >
| > Thoughts?
| 
| 5) Stop leveling down our development, and rely and leverage a powerful
| RDBMS that provides interesting feature, such as PostgreSQL.
| 
| Sorry, had to say it, but it's pissing me off to see the low quality of
| the work that is done around SQL in OpenStack.

[amrith] So, just to be clear, this isn't a bug in MySQL, nor a bug in
Galera. What is happening is actually a pretty subtle issue (documented)
with the way Galera and MySQL work if you use select for update. The
implication that PostgreSQL is "powerful" while using MySQL and Galera is
"low quality" seems a tad bit extreme. I don't believe that anything
implemented precludes the use of PostgreSQL. If you'd like to do that, go
for it since you are a clearly a huge fan of PostgreSQL. 

| 
| --
| Julien Danjou
| /* Free Software hacker
|    http://julien.danjou.info */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6559 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140529/f563c2b9/attachment.bin>


More information about the OpenStack-dev mailing list