-
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
VReplication: Auto renew lease on Keyspace Lock #16240
Conversation
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: Matt Lord <[email protected]>
09e8f62
to
0962e47
Compare
Signed-off-by: Matt Lord <[email protected]>
if si.PrimaryAlias == nil { | ||
return nil, fmt.Errorf("target shard %v has no primary tablet", shard) | ||
} |
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.
This is unrelated, but addresses a panic raised in the Vitess Slack where the target shard had no primary tablet.
Signed-off-by: Matt Lord <[email protected]>
Can't range over a buffered channel to drain it w/o first closing it. Just close it. Signed-off-by: Matt Lord <[email protected]>
13bfb01
to
b1fa06d
Compare
Signed-off-by: Matt Lord <[email protected]>
2172180
to
5dfe973
Compare
Signed-off-by: Matt Lord <[email protected]>
5dfe973
to
7c5c0db
Compare
Signed-off-by: Matt Lord <[email protected]>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #16240 +/- ##
==========================================
- Coverage 68.61% 68.56% -0.06%
==========================================
Files 1544 1544
Lines 197993 198176 +183
==========================================
+ Hits 135848 135874 +26
- Misses 62145 62302 +157 ☔ View full report in Codecov by Sentry. |
73f2808
to
feca7a1
Compare
Signed-off-by: Matt Lord <[email protected]>
feca7a1
to
9f9f13f
Compare
Replaced by: #16260 |
Description
VReplication uses
Keyspace
topo server locks in order to prevent concurrent changes that could cause breakages. It does that in these primary locations:SwitchTraffic
andReverseTraffic
) in various workflows likeMoveTables
andReshard
This is done in order to prevent concurrent changes to shared resources such as the
_vt.vreplication
record on target shards.At some point, I think we should add a distributed
workflow
lock in the topo to coordinate on related issues. We may want those both at a keyspace level and at a shard level — depending on the level of concurrency control we require for the given operation. This lock can then also be held for as long as needed as it would not impact other Vitess operations (the Keyspace Lock is used for things e.g. like updating the throttler config, durability policy, or schema for a keyspace). This will be a major project, however, and for the time being we can instead make a relatively minor change to how theKeyspace
locks are managed in the noted cases within VReplication. In this PR the change is that we automatically renew the Keyspace Lock while holding it, up to a maximum time (hard coded at 10 mins now but will probably add a flag for this ~--max-keyspace-lock-ttl=<duration>
which defaults to 10m).Related Issue(s)
Checklist