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).
> 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.
--
Julien Danjou
/* Free Software hacker
http://julien.danjou.info */
signature.asc
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
