[
https://issues.apache.org/jira/browse/CASSANDRA-19733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860700#comment-17860700
]
Jeff Jirsa commented on CASSANDRA-19733:
----------------------------------------
It shouldn’t ever stream from same rack (same dc but not same rack) because
rack aware snitch shouldn’t have two replicas on the same rack
But streaming from arbitrary dc seems even more likely to violate (dc local)
consistency.
Isn’t the better fix to make it so we can replace hosts mid upgrade instead of
adding a bunch of operator tooling to try to work around the deficiency of the
database ?
> 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 (usually the same rack) 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]
