-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Support specifying expected primary in ERS/PRS #16852
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
Support specifying expected primary in ERS/PRS #16852
Conversation
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
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
|
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
I think I prefer the field-name 🎉 for Or other suggestions appreciated |
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.
LGTM!
|
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.
LGTM. Once the flag name is final, you should edit the PR description to document command usage. I've added a label that prevents merge, and you can remove the label and merge it at that point.
Sounds good! It looks like there weren't many strong opinions on naming I think I've flip/flopped back to leaving this as-is. My reasoning is if I say what I'm asking to do out loud it is "do X reparent and I expect Y to be still be the primary". And I feel adding |
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
* `slack-15.0`: backport PR vitessio#16852 Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com> * make vtadmin_web_proto_types Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com> * fix v15 tests Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com> --------- Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
* Support specifying expected primary in ERS/PRS (vitessio#16852) Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com> * fix typo Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com> --------- Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
Description
This PR allows a
EmergencyReparentShard
/PlannedReparentShard
request to contain the alias of the primary we expect to be the current primary for the action to succeed. If this alias is incorrect or stale, the reparent fails with an error indicating there is a failed precondition/mismatch.This is useful to prevent races between external automation that runs reparents and Vitess (
vtorc
andvtctld
), which may reparent a shard in the time external automation is creating/processing it's own reparent request. With this support added, automation with a stale view of the world will encounter an error instead of triggering an potentially unnecessary reparentIn the future, Vitess could use this field internally to be more explicit but because everything uses shard locks, it should never encounter a mismatch
Related Issue(s)
Resolves #16430
Checklist
Deployment Notes