[
https://issues.apache.org/jira/browse/CASSANDRA-21174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18059808#comment-18059808
]
Sam Tunnicliffe commented on CASSANDRA-21174:
---------------------------------------------
I agree with [~marcuse], {{Transformation}} implementations can't be affected
by external state like system properties or node config which could cause
different outcomes on different nodes. Some previous issues where we have
encountered similar issues are
* CASSANDRA-20452
* CASSANDRA-20287
* CASSANDRA-20600
The whole paradigm of an immutable metadata log is still new to Cassandra, so
it's not unexpected that we bump into these issues from time to time. I expect
that as we get closer to a 6.0 release contributors will naturally become more
accustomed to working on trunk and this will become more familiar.
Regarding this particular issue, the good news is that stated goal is already
the implemented behaviour. Should a node running an incompatible version (i.e.
one where the {{NodeVersion.CURRENT_METADATA_VERSION}} is lower that the
cluster's minimum common version), it will be prevented from starting up. This
happens as a natural consequence of fetching the initial cluster metadata state
from the CMS, which is serialized using the minimum common version. As the new
node is unaware of this version, it is unable to deserialize it and startup is
halted. Testing this is a bit tricky as we only currently have an established
path for testing upgrades where nodes all start on one version and progress to
a later version. However, it is possible to emulate this behaviour in tests
without actually having nodes running multiple versions. I've pushed an example
of this
[here|https://github.com/beobal/cassandra/commit/69ea018c260126e051782e864a04795a41952a1a]
for reference.
All that said, I do think there is still value the extra checks you added the
two transformations, I just think we should remove the system property and the
ability to bypass them.
> Forbid nodes upgrading to a version which cannot read existing log entries
> --------------------------------------------------------------------------
>
> Key: CASSANDRA-21174
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21174
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
> Reporter: Aparna Naik
> Assignee: Aparna Naik
> Priority: Normal
> Fix For: 6.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> It should not be possible for a node to join a cluster (either via bootstrap
> or by replacing an existing member), unless the minimum metadata
> serialization it supports is at least equal to the cluster's
> minCommonSerializationVersion. This is to prevent nodes being unable to read
> log entries or metadata snapshots when joining the cluster.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
