Throttler: fix to client usage in vreplication and table GC#7422
Merged
rohit-nayak-ps merged 1 commit intovitessio:masterfrom Feb 4, 2021
Merged
Conversation
Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
shlomi-noach
requested review from
harshit-gangal,
rohit-nayak-ps and
systay
as code owners
shlomi-noach
added a commit
to planetscale/vitess
that referenced
this pull request
Feb 1, 2021
Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
In #7364 we introduced client.go, a throttler client, which we then used in tabletserver/tablegc, vreplication/engine and vstreamer/engine.
In the first two, I used the wrong check type:
ThrottleCheckSelf, where in fact I should have usedThrottleCheckPrimaryWritebecause table GC and vreplication/engine both write to a primary and should therefore consider replication lag on the shard. This must have been a copy+paste mistake.The reason endtoend tests didn't catch this is that we don't have the capacity to run replicas on our vreplication tests, and so we only have primaries; in that scenario both types of checks converge to the same result.
Related Issue(s)
Tracking: #7362
Checklist
Impacted Areas in Vitess
Components that this PR will affect: