-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
kvserver: allocating replacement replicas needs to consider fully satisfying constraints #94809
Labels
A-kv-decom-rolling-restart
Decommission and Rolling Restarts
A-kv-distribution
Relating to rebalancing and leasing.
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
T-kv
KV Team
Comments
AlexTalks
added
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
A-kv-distribution
Relating to rebalancing and leasing.
A-kv-decom-rolling-restart
Decommission and Rolling Restarts
T-kv
KV Team
labels
Jan 6, 2023
This comment on cockroach/pkg/kv/kvserver/allocator/allocatorimpl/allocator_scorer.go Lines 1797 to 1800 in 71f9712
Except, clearly, we don't enforce this, and we allow there to be "unconstrained" replicas. It seems that those need to be accounted for. |
Nice find! |
cc. @joshimhoff |
AlexTalks
added a commit
to AlexTalks/cockroach
that referenced
this issue
Feb 6, 2023
This change adds tests using `store.AllocatorCheckRange(..)` to investigate the behavior or attempting to decommission a node when doing so would cause constraints to be broken. This test is needed because it was uncovered recently that a partially constrained range (i.e. a range configured with `num_replicas = 3, constraint = '{<some constraint>: 1}'` may not have the constraint fully respected if the only node that satisfies said constraint is being decommissioned. Part of cockroachdb#94809 Depends on cockroachdb#94024. Release note: None
AlexTalks
added a commit
to AlexTalks/cockroach
that referenced
this issue
Feb 6, 2023
This changes the allocator to be fully aware of the replica that is beingn replaced when allocating new target replicas due to a dead or decommissioning node. This ensures that if constraints were respected before the dead or decommissioning node left the cluster, they will still be respected afterwards, particularly in the case at issue, which is when partial constraints are set on a range (e.g. `num_replicas = 3, <some_constraint>: 1`). This is achieved by rejecting candidate stores to allocate the replacement on when they do not satisfy a constraint that was satisfied by the existing store. In doing so, this means that some node decommissions that would previously be able to execute will now not allow the user to decommission the node and violate the configured constraints. Fixes cockroachdb#94809. Release note (bug fix): Decommissions that would violate constraints set on a subset of replicas for a range (e.g. `num_replicas = 3, <constraint>: 1`) will no longer be able to execute, respecting constraints during and after the decommission.
AlexTalks
added a commit
to AlexTalks/cockroach
that referenced
this issue
Feb 8, 2023
This change adds tests using `store.AllocatorCheckRange(..)` to investigate the behavior or attempting to decommission a node when doing so would cause constraints to be broken. This test is needed because it was uncovered recently that a partially constrained range (i.e. a range configured with `num_replicas = 3, constraint = '{<some constraint>: 1}'` may not have the constraint fully respected if the only node that satisfies said constraint is being decommissioned. Part of cockroachdb#94809 Depends on cockroachdb#94024. Release note: None
AlexTalks
added a commit
to AlexTalks/cockroach
that referenced
this issue
Feb 8, 2023
This changes the allocator to be fully aware of the replica that is beingn replaced when allocating new target replicas due to a dead or decommissioning node. This ensures that if constraints were respected before the dead or decommissioning node left the cluster, they will still be respected afterwards, particularly in the case at issue, which is when partial constraints are set on a range (e.g. `num_replicas = 3, <some_constraint>: 1`). This is achieved by rejecting candidate stores to allocate the replacement on when they do not satisfy a constraint that was satisfied by the existing store. In doing so, this means that some node decommissions that would previously be able to execute will now not allow the user to decommission the node and violate the configured constraints. Fixes cockroachdb#94809. Release note (bug fix): Decommissions that would violate constraints set on a subset of replicas for a range (e.g. `num_replicas = 3, <constraint>: 1`) will no longer be able to execute, respecting constraints during and after the decommission.
AlexTalks
added a commit
to AlexTalks/cockroach
that referenced
this issue
Feb 9, 2023
This change adds tests using `store.AllocatorCheckRange(..)` to investigate the behavior or attempting to decommission a node when doing so would cause constraints to be broken. This test is needed because it was uncovered recently that a partially constrained range (i.e. a range configured with `num_replicas = 3, constraint = '{<some constraint>: 1}'` may not have the constraint fully respected if the only node that satisfies said constraint is being decommissioned. Part of cockroachdb#94809 Depends on cockroachdb#94024. Release note: None
AlexTalks
added a commit
to AlexTalks/cockroach
that referenced
this issue
Feb 9, 2023
This changes the allocator to be fully aware of the replica that is beingn replaced when allocating new target replicas due to a dead or decommissioning node. This ensures that if constraints were respected before the dead or decommissioning node left the cluster, they will still be respected afterwards, particularly in the case at issue, which is when partial constraints are set on a range (e.g. `num_replicas = 3, <some_constraint>: 1`). This is achieved by rejecting candidate stores to allocate the replacement on when they do not satisfy a constraint that was satisfied by the existing store. In doing so, this means that some node decommissions that would previously be able to execute will now not allow the user to decommission the node and violate the configured constraints. Fixes cockroachdb#94809. Release note (bug fix): Decommissions that would violate constraints set on a subset of replicas for a range (e.g. `num_replicas = 3, <constraint>: 1`) will no longer be able to execute, respecting constraints during and after the decommission.
AlexTalks
added a commit
to AlexTalks/cockroach
that referenced
this issue
Feb 15, 2023
This change adds tests using `store.AllocatorCheckRange(..)` to investigate the behavior or attempting to decommission a node when doing so would cause constraints to be broken. This test is needed because it was uncovered recently that a partially constrained range (i.e. a range configured with `num_replicas = 3, constraint = '{<some constraint>: 1}'` may not have the constraint fully respected if the only node that satisfies said constraint is being decommissioned. Part of cockroachdb#94809 Depends on cockroachdb#94024. Release note: None
craig bot
pushed a commit
that referenced
this issue
Feb 15, 2023
94810: kvserver: fix constraint analysis on replica replacement r=AlexTalks a=AlexTalks This changes the allocator to be fully aware of the replica that is beingn replaced when allocating new target replicas due to a dead or decommissioning node. This ensures that if constraints were respected before the dead or decommissioning node left the cluster, they will still be respected afterwards, particularly in the case at issue, which is when partial constraints are set on a range (e.g. `num_replicas = 3, <some_constraint>: 1`). This is achieved by rejecting candidate stores to allocate the replacement on when they do not satisfy a constraint that was satisfied by the existing store. In doing so, this means that some node decommissions that would previously be able to execute will now not allow the user to decommission the node and violate the configured constraints. Fixes #94809. Depends on #94024. Release note (bug fix): Decommissions that would violate constraints set on a subset of replicas for a range (e.g. `num_replicas = 3, <constraint>: 1`) will no longer be able to execute, respecting constraints during and after the decommission. Co-authored-by: Alex Sarkesian <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-kv-decom-rolling-restart
Decommission and Rolling Restarts
A-kv-distribution
Relating to rebalancing and leasing.
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
T-kv
KV Team
In a recent investigation, it was discovered that when we have constraints applying to some but not all the replicas needed for a range, it is possible for a replacement operation (such as during decommission) to not consider that all constraints are no longer satisfied. This occurs when we have configurations such as
num_replicas = 3, constraints = '{<some constraint>: 1}'
, and thus would expect to have 2 replicas that do not need to satisfy any constraints, known as "unconstrained replicas"; however replacement of the one replica that satisfies the constraint should not be possible.This can be reproduced simply with the following:
Jira issue: CRDB-23152
The text was updated successfully, but these errors were encountered: