You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sam Tunnicliffe (JIRA)" <ji...@apache.org> on 2019/01/28 19:31:00 UTC

[jira] [Commented] (CASSANDRA-14802) calculatePendingRanges assigns more pending ranges than necessary

    [ https://issues.apache.org/jira/browse/CASSANDRA-14802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754286#comment-16754286 ] 

Sam Tunnicliffe commented on CASSANDRA-14802:
---------------------------------------------

During concurrent replacements without any actual range movements occurring, the pending ranges calculation can also be incorrect due to the fact that we don't differentiate between {{BOOTSTRAP}} and {{BOOTSTRAP_REPLACE}}.
Updating {{allLeftMetadata}} with the tokens & endpoint for a {{BOOTSTRAP_REPLACE}} doesn't grow the ring as it's a straight up replacement, so the subsequent removal of the new endpoint after we grab its new ranges actually constitutes a shrink, skewing the ownership represented by {{allLeftMetadata}}. If there are concurrent replacements happening, this then makes the pending ranges calculation for those tokens completely off.




> 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org