[
https://issues.apache.org/jira/browse/CASSANDRA-14802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-14802:
----------------------------------------
Status: Patch Available (was: Open)
The {{BOOTSTRAP_REPLACE}} case is, I think, relatively straightforward to fix.
As this is fairly simple to reason about/implement/test, IMO we could consider
it for 4.0 and defer the more complex general case for now. This isn't a new
regression and getting it right (& validating it) is going to be quite
involved, so it feels a bit of a risk for the 4.0 timeframe.
||branch||CI||
|[14802-trunk|https://github.com/beobal/cassandra/tree/14802-trunk]|[circle|https://circleci.com/gh/beobal/workflows/cassandra/tree/cci%2F14802-trunk]|
> calculatePendingRanges assigns more pending ranges than necessary
> ------------------------------------------------------------------
>
> Key: CASSANDRA-14802
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14802
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Distributed Metadata
> Reporter: Benedict
> Priority: Major
> Fix For: 4.x
>
>
> This might be a good thing, but should probably be configurable, and made
> consistent. Presently, in a number of circumstances where there are multiple
> range movements, {{calculatePendingRanges}} will assign a pending range to a
> node that will not ultimately own it. If done consistently, this might make
> range movements resilient to node failures / aborted range movements, since
> all nodes will be receiving all ranges they might own under any incomplete
> range ownership movements. But done inconsistently it seems only to reduce
> availability in the cluster, by potentially increasing the number of pending
> nodes unnecessarily.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
