-
Notifications
You must be signed in to change notification settings - Fork 2.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
Handle MySQL handler error codes #17252
Conversation
Signed-off-by: Shlomi Noach <[email protected]>
Review ChecklistHello reviewers! 👋 Please follow this checklist when reviewing this Pull Request. General
Tests
Documentation
New flags
If a workflow is added or modified:
Backward compatibility
|
sqlerror.HaErrDiskFullNowait: | ||
log.Errorf("Got unrecoverable error: %v", sqlErr) | ||
return true | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shlomi-noach Isn't it easier to invert this and only here have explicit error codes that are recoverable? That's I think also more robust for new error codes etc. in the future to assume it's not recoverable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm ambivalent. On one hand, until today I have never encountered this error in Vitess. On the other hand, I'm afraid to introduce new (so called "unaccounted for") failure points.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd lean towards treating unknown things then as not recoverable / retryable? Seems less risky to keep hammering on something that is an unexpected / unknown failure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We now opt-in for recoverable errors.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #17252 +/- ##
==========================================
+ Coverage 67.39% 67.42% +0.02%
==========================================
Files 1570 1570
Lines 252917 252934 +17
==========================================
+ Hits 170446 170529 +83
+ Misses 82471 82405 -66 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]> Signed-off-by: Renan Rangel <[email protected]>
Description
Some of MySQL errors include more fine grained handler error codes, as seen in
For example:
ERROR HY000: Got error 149 - 'Lock deadlock; Retry transaction' during COMMIT
Another example:
ER_ERROR_DURING_COMMIT
as described in #17248.With this PR we formally introduce
HandlerErrorCode
. We addSQLError.HaErrorCode()
which uses regexp parsing on the error message to extract the handler error code, if any.Furthermore, some of these handler error codes indicate an unrecoverable error for vreplication.
We meanwhile add a sample of those.We list the full range of existing HA errors, and mark a select few as recoverable.Related Issue(s)
#17248
Checklist
Deployment Notes