[
https://issues.apache.org/jira/browse/CASSANDRA-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18102619#comment-18102619
]
Matt Byrd commented on CASSANDRA-16290:
---------------------------------------
This is still a problem on all versions but can be fixed potentially slightly
more favourably both post and pre TCM.
CC [~samt] [~maedhroz]
The problem arises when the decommissioning node moves back to NORMAL and hence
the nodes it was streaming to are no longer pending endpoints and fail to
receive mutations before a decommission is resumed.
If instead we can distinguish, is this a true resumption (i.e we have not run
abortdecommission post TCM) and so have the endpoints remained pending this
entire time, then we do not need to clear the relevant transferred_ranges_v2
and equivalent legacy table.
This is more clearly available post TCM, but seems possibly before also, I've
attached links to PRS for each of the 5 branches and will attach CI in a sec:
4.0: [https://github.com/apache/cassandra/pull/5003/]
4.1: [https://github.com/apache/cassandra/pull/5002/]
5.0: [https://github.com/apache/cassandra/pull/5000/]
6.0: [https://github.com/apache/cassandra/pull/5001/]
trunk: [https://github.com/apache/cassandra/pull/4999/]
> Consistency can be violated when bootstrap or decommission is resumed after
> node restart
> ----------------------------------------------------------------------------------------
>
> Key: CASSANDRA-16290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16290
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
> Reporter: Paulo Motta
> Assignee: Bartlomiej
> Priority: Normal
> Labels: lhf
> Fix For: 4.0.x, 4.1.x, 5.0.x, 6.x, 7.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since CASSANDRA-12008, successfully transferred ranges during decommission
> are saved on the {{system.transferred_ranges}} table. This allow skipping
> ranges already transferred when a failed decommission is retried with
> {{nodetool decommission}}.
> If instead of resuming the decommission, an operator restarts the node, waits
> N minutes and then performs a new decommission, the previously transferred
> ranges will be skipped during streaming, and any writes received by the
> decommissioned node during these N minutes will not be replicated to the new
> range owner, what violates consistency.
> This issue is analogous to the issue mentioned [on this
> comment|https://issues.apache.org/jira/browse/CASSANDRA-8838?focusedCommentId=16900234&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16900234]
> for resumable bootstrap (CASSANDRA-8838).
> In order to prevent consistency violations we should clear the
> {{system.transferred_ranges}} state during node restart, and maybe a system
> property to disable it. While we're at this, we should change the default of
> {{-Dcassandra.reset_bootstrap_progress}} to {{true}} to clear the
> {{system.available_ranges}} state by default when a bootstrapping node is
> restarted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
