[ 
https://issues.apache.org/jira/browse/CASSANDRA-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641705#comment-17641705
 ] 

Yuki Morishita edited comment on CASSANDRA-8110 at 12/7/22 4:05 AM:
--------------------------------------------------------------------

I'd like to propose a possible solution to achieve the goal to allow streaming 
in the cluster with mixed versions of nodes, which typically happens when 
rolling upgrading the cluster.

The current consensus of the node failure during the upgrade process is to 
continue upgrading the cluster and perform the node replacement after the nodes 
are in the same version, since the streaming across the different versions are 
prevented/not guaranteed to work. This behavior makes a large cluster upgrade 
that requires high availability nearly impossible, since rolling upgrades can 
create downtime with failed nodes.

To achieve this goal, I propose the following changes to Apache Cassandra:
 * Use the same (old) SSTable version in the upgraded node to write SSTables, 
until all the nodes in the cluster are in the same Cassandra version
 ** SSTable version has been in gossip state (SSTABLE_VERSIONS) since 
CASSANDRA-15897. We can use this to determine which SSTable version to use in 
the upgraded node.
 ** We need to bring back old SSTableWriter implementations or implement 
versioned serialization to SSTableWriter.
 ** The nodes in the cluster can switch to a new SSTable version using 
Cassandra Version (RELEASE_VERSION)  in gossip state.

 * Accept the stream from older version
 ** Right now, the streaming protocol version needs to be the same in sender 
and receiver. We need to relax this constraint.

These two can be worked on separately. SSTable version fixation alone can allow 
mixed version streaming using the *current* streaming protocol version. For 
example, if SSTable version is updated with this feature in  5.0, and still use 
the same streaming protocol version, Cassandra 4.0/4.1 and 5.0 can still 
perform streaming (forward compatibility).

If we want to extend this feature to older versions of Cassandra (backward 
compatibility), we need to add a streaming protocol compatible layer to 
understand previous versions of streaming protocol (if any).

I'd like to hear opinions about this approach from the community, and if it 
seems feasible, I'd like to start implementing this change.


was (Author: yukim):
I'd like to propose a possible solution to achieve the goal to allow streaming 
in the cluster with mixed versions of nodes, which typically happens when 
rolling upgrading the cluster.

The current consensus of the node failure during the upgrade process is to 
continue upgrading the cluster and perform the node replacement after the nodes 
are in the same version, since the streaming across the different versions are 
prevented/not guaranteed to work. This behavior makes a large cluster upgrade 
that requires high availability nearly impossible, since rolling upgrades can 
create downtime with failed nodes.

To achieve this goal, I propose the following changes to Apache Cassandra:
 * Use the same (old) SSTable version in the upgraded node to write SSTables, 
until all the nodes in the cluster are in the same Cassandra version
 * SSTable version has been in gossip state (SSTABLE_VERSIONS) since 
CASSANDRA-15897. We can use this to determine which SSTable version to use in 
the upgraded node.
 * We need to bring back old SSTableWriter implementations or implement 
versioned serialization to SSTableWriter.
 * The nodes in the cluster can switch to a new SSTable version using Cassandra 
Version (RELEASE_VERSION)  in gossip state.


 * Accept the stream from older version
 * Right now, the streaming protocol version needs to be the same in sender and 
receiver. We need to relax this constraint.

These two can be worked on separately. SSTable version fixation alone can allow 
mixed version streaming using the *current* streaming protocol version. For 
example, if SSTable version is updated with this feature in  5.0, and still use 
the same streaming protocol version, Cassandra 4.0/4.1 and 5.0 can still 
perform streaming (forward compatibility).

If we want to extend this feature to older versions of Cassandra (backward 
compatibility), we need to add a streaming protocol compatible layer to 
understand previous versions of streaming protocol (if any).

I'd like to hear opinions about this approach from the community, and if it 
seems feasible, I'd like to start implementing this change.

> Make streaming forward & backwards compatible
> ---------------------------------------------
>
>                 Key: CASSANDRA-8110
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8110
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Legacy/Streaming and Messaging
>            Reporter: Marcus Eriksson
>            Priority: Normal
>              Labels: gsoc2016, mentor
>
> To be able to seamlessly upgrade clusters we need to make it possible to 
> stream files between nodes with different StreamMessage.CURRENT_VERSION



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to