[
https://issues.apache.org/jira/browse/CASSANDRA-19733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860702#comment-17860702
]
Yuki Morishita commented on CASSANDRA-19733:
--------------------------------------------
> It shouldn’t ever stream from same rack (same dc but not same rack)
Right, my bad. But still, there is a chance you cannot stream from another
racks mid upgrade.
And yes, this proposal is rather a workaround as you mentioned.
5.0+ already has `storage_compatibility_mode` so when upgrading 4.1 -> 5.0+,
the user can replace the node mid upgrade(Need more testing for this though).
So, the intention of this improvement is to help the users on 3.11.x, 4.0 to
upgrade to 4.1.
> Add feature to filter streaming source when bootstrapping
> ---------------------------------------------------------
>
> Key: CASSANDRA-19733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19733
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Membership
> Reporter: Yuki Morishita
> Assignee: Yuki Morishita
> Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> h2. Proposed improvement
> Right now, the stream sources for the bootstrap are chosen from the closest
> nodes of the bootstrapping node.
> Add the following system properties so that when bootstrap happens, the node
> can choose where to stream data from.
> * {{cassandra.bootstrap.include_dcs}}
> * {{cassandra.bootstrap.exclude_dcs}}
> * {{cassandra.bootstrap.include_sources}}
> {{cassandra.bootstrap.include_dcs and }}{{cassandra.bootstrap.exclude_dcs can
> take args like "dc1,dc2" to specify DCs or "dc1:rack1,dc1:rack2,..." to
> specify DC/Racks.}}
> {{cassandra.bootstrap.include_sources is used to specify ip address/port of
> the specific nodes to stream from.}}
> h2. Motivation
> Currently, when the node failure happens in the middle of the major cluster
> upgrade, general advice given to the user is to complete the upgrade of the
> cluster until all nodes are in the same version, and replace/remove the
> failed node. This is because the streaming breaks when there is unsupported
> SSTable version streamed from newer to the older.
> This approach can create availability issue when two nodes (the failed node
> from different rack and the node currently stopped for the upgrade) are down.
> With this improvement, the user can replace the failed node using, for
> example, specific rack in the same DC or another DC, to eliminate the
> availability issue described above.
> h2. Note
> The user also needs to set "-Dcassandra.skip_schema_check=true" when
> replacing the node during the major upgrade to complete the replacement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
