[
https://issues.apache.org/jira/browse/CASSANDRA-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18102828#comment-18102828
]
Matt Byrd edited comment on CASSANDRA-16290 at 8/7/26 4:26 PM:
---------------------------------------------------------------
I don't feel too strongly about this one, the machinery is there to be able to
use this table scoped by operation/keyspace, but in practice we never do. The
only readers are migration between versions of the table and decommission and
the table as created doesn't really make sense for rebuild, move or removenode.
For all of those you actually want a distributed table to store data, because
the streamer and hence updater of this state, may not be the same node that you
issue the operation on.
I think if anyone seriously thought about making a resumable move, rebuild or
removenode, they'd need a new distributed table and wouldn't re-use this one.
So in practice I think truncate is probably fine and the upside is it makes the
5 patches closer to each other.
I'll apply your suggestion [~samt] unless anyone has any good reasons otherwise.
was (Author: mbyrd):
I don't feel too strongly about this one, the machinery is there to be able to
use this table scoped by operation/keyspace, but in practice we never do.
The only readers are migration between versions of the table and decommission
and the table as created doesn't really make sense for rebuild, move or
removenode.
For all of those you actually want a distributed table to store data, because
the streamer and hence updater of this state, may not be the same node that you
issue the operation on.
I think if anyone seriously thought about making a resumable move, rebuild or
removenode, they'd need a new distributed table and wouldn't re-use this one.
So in practice I think truncate is probably fine and the upside is it makes the
5 patches closer to each other.
I'll apply your suggestion [~samt] unless anyone has any good reasons otherwise.
> 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: Matt Byrd
> Priority: Normal
> Labels: lhf
> Fix For: 4.0.x, 4.1.x, 5.0.x, 6.x, 7.x
>
> Attachments: mbyrd_CASSANDRA-16290_4.0.html,
> mbyrd_CASSANDRA-16290_4.1.html, mbyrd_CASSANDRA-16290_5.0.html,
> mbyrd_CASSANDRA-16290_6.0.html, mbyrd_CASSANDRA-16290_trunk.html
>
> 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]
