You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Yuki Morishita (Jira)" <ji...@apache.org> on 2022/12/07 04:06:00 UTC
[jira] [Comment Edited] (CASSANDRA-8110) Make streaming forward & backwards compatible
[ 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org