Open Stack

On Tue, Jun 16, 2015 at 2:18 PM, Salvatore Orlando <sorlando at nicira.com> wrote:
> But zzzeek (Mike Bayer) is coming to our help; as a part of his DBFacade
> work, we should be able to treat active/active cluster as active/passive for
> writes, and active/active for reads. This means that the write set
> certification issue just won't show up, and the benefits of active/active
> clusters will still be attained for most operations (I don't think there's
> any doubt that SELECT operations represent the majority of all DB
> statements).

Okay, so we stop worrying about the write certification failures?
Lock for update would work as expected?  That would certainly simplify
the Galera concern.  Maybe everyone already knew this and I have just
been behind on the latest news again.

> DBDeadlocks without multiple workers also suggest we should look closely at
> what eventlet is doing before placing the blame on pymysql. I don't think
> that the switch to pymysql is changing the behaviour of the database
> interface; I think it's changing the way in which neutron interacts to the
> database thus unveiling concurrency issues that we did not spot before as we
> were relying on a sort of implicit locking triggered by the fact that some
> parts of Mysql-Python were implemented in C.

++

Carl