Details
Description
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 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.
Attachments
Issue Links
- is duplicated by
-
CASSANDRA-15264 Make resumable bootstrap off by default
- Resolved
- is related to
-
CASSANDRA-8838 Resumable bootstrap streaming
- Resolved
-
CASSANDRA-12008 Make decommission operations resumable
- Resolved
- relates to
-
CASSANDRA-17679 Make resumable bootstrap feature optional
- Resolved
- links to