-
Notifications
You must be signed in to change notification settings - Fork 11.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[5.2] Handle InnoDB Deadlocks By Re-Attempting Transactions #12151
Conversation
Handle InnoDB Deadlocks By Re-Attempting Transactions
This needs to go to 5.1. |
Should I do another pull request at 5.1 branch? |
Correct me if I'm wrong, but just to clarify, I'm pretty sure this retries the MySQL connection, not the actual transaction in deadlock. |
@InstanceOfMichael is right! This doesn't solve the problem at all, it just tries to call reconnect, which still makes deadlocks fail because you can't reconnect when there is an open transaction in MySQL waiting to be finished. In no way does this fix #5380 at all. If anything it just compounds the problem! |
I cannot actually test the patch, the deadlocks happen on a 4.2 app. But correct me if i'm wrong, this error happens even if you are not using transactions (atleast on Galera cluster) and in that case, this should work. There is any way to trigger this deadlock on a single instance mariaDB? I'll be happy to provide a full patch to fix this issue. |
Yes, it solves the issue in a single use case. But that's not the cause in the issue it pupports to fix (#5380). When a deadlock happens in normal use cases, this added line will cause your DB to reconnect and to re-try to query that was deadlocked, which is fine! The problem is that if you have started a
|
Yes, the pull request is definitely important and a bugfix, but the description of the bugfix is misleading (or blatantly wrong). If anyone actually wants automatic retries, they'll need to write their own fancy |
For me, automatic retries aren't even a problem. The problem lies in the fact that the framework tries to force a reconnect regardless of the nature of the query being run. If a Edit: Until after |
But I've never written anything. |
The other issue at play here is that you are also treating a Deadlock as a Disconnect, which is also not the case. A deadlock and a disconnect are two completely separate things. In a nutshell, a Deadlock needs to either retry or discard (and rollback if you are in a transaction), not force a reconnect because a Deadlock is not a disconnect @InstanceOfMichael That would actually make a lot of sense. A decent transaction builder would be lovely to have in here, especially if you can specify a retry count before discard and rollback. |
Should this be reverted? Could someone with some more knowledge make a PR? |
NB If it is reverted, or simply repaired, this will need to happen on 5.1. |
Probably, I have an exception where I attempt to
|
…ttempting Transactions
On MySQL galera cluster, deadlocks happens very often. Fixes #5380