Paulo Motta created CASSANDRA-16290:
---------------------------------------
Summary: 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: Cassandra
Issue Type: Bug
Components: Consistency/Bootstrap and Decommission
Reporter: Paulo Motta
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.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
