in-progress queries are intolerant of mysql restarts

Bug #1040694 reported by Therese McHale
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Glance
In Progress
Wishlist
Therese McHale
OpenStack Compute (nova)
Won't Fix
Wishlist
Unassigned
oslo.db
Confirmed
Wishlist
Unassigned

Bug Description

Glance is intolerant of mysql restarts with running queries and the currently ping_listener/wrap_db_error mechanism does not work for running queries. This was logged in Bug #954971 and a solution (using wrap_db for queries) merged. The fix was removed in Bug #967887 as it did not work with later versions of sqlalchemy.
An alternative approach is to use the sqlalchemy create_engine "module" parameter to override the engine behaviour and do the wrapping there. (Mike Bayer of sqlalchemys recommended solution) I will attach a patch which does this

Tags: db
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to glance (master)

Fix proposed to branch: master
Review: https://review.openstack.org/11874

Changed in glance:
assignee: nobody → Therese McHale (therese-mchale)
status: New → In Progress
Revision history for this message
Brian Waldon (bcwaldon) wrote :

Let's look at this in Grizzly

summary: - glance is intolerant of mysql restarts
+ in-progress queries are intolerant of mysql restarts
Changed in glance:
importance: Undecided → Wishlist
aeva black (tenbrae)
Changed in nova:
assignee: nobody → Devananda (devananda)
Dan Prince (dan-prince)
Changed in nova:
importance: Undecided → Wishlist
status: New → Triaged
tags: added: db
Revision history for this message
Viktor Serhieiev (vsergeyev) wrote :

Well, oslo.db supports retrying of transactions. Folks, from Glance/Nova - can you please check it?

Changed in oslo.db:
status: New → Incomplete
Revision history for this message
Viktor Serhieiev (vsergeyev) wrote :

Mark as Incomplete in oslo.db because of low information about a bug

Revision history for this message
Mike Bayer (zzzeek) wrote :

I think part of the topic here is that there are two ways I've proposed of retrying transactions. The simple, easy and boring one we have is the wrap_db_retry() decorator. The other one is an exotic event-based approach I did for a client, which I feel is pretty experimental which is over at https://bitbucket.org/zzzeek/sqlalchemy/issue/3104/transaction-replay-extension , the attached patch is already in production elsewhere. The experimental design actually records all the SQL as the transaction proceeds, intercepts a selected set of exceptions as "good for retry" and then replays a subset of that SQL back, namely the DML. This is a very exotic way to go as it makes a lot of assumptions that those same INSERT/UPDATE/DELETE statements are still valid, even though we're in a new transaction.

I have a notion that we should ultimately have all methods that start using a database transaction wrapped in a decorator that establishes this context. The retry of the whole method should probably be rolled into that decorator.

Sean Dague (sdague)
Changed in nova:
assignee: Devananda van der Veen (devananda) → nobody
Revision history for this message
Sean Dague (sdague) wrote :

I'm not clear where this bug still stands. Marking as incomplete for Nova.

Changed in nova:
status: Triaged → Incomplete
Revision history for this message
Markus Zoeller (markus_z) (mzoeller) wrote :

This bug has the status "incomplete" for more than 30 days. It is unclear if this is an "invalid" bug or if it is an "opinion". I set it to "won't fix".
Feel free to reopen the bug by providing the requested information and set the bug status back to "New".

Changed in nova:
status: Incomplete → Won't Fix
Revision history for this message
Roman Podoliaka (rpodolyaka) wrote :

On oslo.db side we can track this as a feature request for EngineFacade to be able to retry transactions automatically.

Changed in oslo.db:
status: Incomplete → Confirmed
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.