[
https://issues.apache.org/jira/browse/CASSANDRA-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17770086#comment-17770086
]
Jeremy Hanna commented on CASSANDRA-8110:
-----------------------------------------
[~yukim] is this done with what [~Bereng] did on CASSANDRA-14227?
Specifically, the {{storage_compatibility_mode}} as described in the latest
cassandra.yaml
([here|https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L2090-L2115]
is the block from cassandra.yaml):
{code:java}
# This property indicates with what Cassandra major version the storage format
will be compatible with.
#
# The chosen storage compatiblity mode will determine the versions of the
written sstables, commitlogs, hints,
# etc. Those storage elements will use the higher minor versions of the major
version that corresponds to the
# Cassandra version we want to stay compatible with. For example, if we want to
stay compatible with Cassandra 4.0
# or 4.1, the value of this property should be 4, and that will make us use
'nc' sstables.
#
# This will also determine if certain features depending on newer formats are
available. For example, extended TTLs
# up to 2106 depend on the sstable, commitlog, hints and messaging versions
that were introduced by Cassandra 5.0,
# so that feature won't be available if this property is set to CASSANDRA_4.
See upgrade guides for details. Currently
# the only supported major is CASSANDRA_4.
#
# Possible values are in the StorageCompatibilityMode.java file accessible
online. At the time of writing these are:
# - CASSANDRA_4: Stays compatible with the 4.x line in features, formats and
component versions.
# - UPGRADING: The cluster monitors nodes versions during this interim stage.
_This has a cost_ but ensures any new features,
# formats, versions, etc are enabled safely.
# - NONE: Start with all the new features and formats enabled.
#
# A typical upgrade would be:
# - Do a rolling upgrade starting all nodes in CASSANDRA_Y compatibility mode.
# - Once the new binary is rendered stable do a rolling restart with UPGRADING.
The cluster will enable new features in a safe way
# until all nodes are started in UPGRADING, then all new features are enabled.
# - Do a rolling restart with all nodes starting with NONE. This sheds the
extra cost of checking nodes versions and ensures
# a stable cluster. If a node from a previous version was started by accident
we won't any longer toggle behaviors as when UPGRADING.
#
storage_compatibility_mode: CASSANDRA_4 {code}
> 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
