[
https://issues.apache.org/jira/browse/CASSANDRA-20145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-20145:
----------------------------------------
Description:
Downgrading from current trunk to 5.0 should be unproblematic as (currently)
there are no changes to on disk format or existing system tables.
Rolling back to 4.x is also possible while the upgraded nodes are configured
with storage compatibility mode {{CASSANDRA_4}}. However, this also means peers
are unable to use messaging {{VERSION_51}}, so some of the guarantees around
consistency and visibility of metadata changes are weakened as these depend on
encoding metadata epochs in internode messages. Those limitations aside, the
cluster can be operated as normal following the upgrade with schema and
topology changes permitted. The effects of these changes persist through a
downgrade. The downgrade requires operators to manually remove some directories
on disk, but can be done online without taking down the entire cluster.
-There's one problem with this at the moment; in trunk an extra identifier is
included in gossip digest syn messages to help guard against split brain
scenarios when intialising a new cluster. Running with {{CASSANDRA_4}}
compatibility currently causes the checking of this identifier to error which
prevents the CMS being initialised (via {{nodetool cms initialize}}) during the
5.1 upgrade.- edit: this is no longer an issue
was:
Downgrading from current trunk to 5.0 should be unproblematic as (currently)
there are no changes to on disk format or existing system tables.
Rolling back to 4.x is also possible while the upgraded nodes are configured
with storage compatibility mode {{CASSANDRA_4}}. However, this also means peers
are unable to use messaging {{VERSION_51}}, so some of the guarantees around
consistency and visibility of metadata changes are weakened as these depend on
encoding metadata epochs in internode messages. Those limitations aside, the
cluster can be operated as normal following the upgrade with schema and
topology changes permitted. The effects of these changes persist through a
downgrade. The downgrade requires operators to manually remove some directories
on disk, but can be done online without taking down the entire cluster.
There's one problem with this at the moment; in trunk an extra identifier is
included in gossip digest syn messages to help guard against split brain
scenarios when intialising a new cluster. Running with {{CASSANDRA_4}}
compatibility currently causes the checking of this identifier to error which
prevents the CMS being initialised (via {{nodetool cms initialize}}) during the
5.1 upgrade.
> Ensure downgrade from 5.1 to 4.x is possible
> --------------------------------------------
>
> Key: CASSANDRA-20145
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20145
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Local/Other
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Priority: Normal
> Fix For: 6.0-alpha1, 6.0
>
> Attachments: ci_summary.html, upgrade_downgrade_script.txt
>
>
> Downgrading from current trunk to 5.0 should be unproblematic as (currently)
> there are no changes to on disk format or existing system tables.
> Rolling back to 4.x is also possible while the upgraded nodes are configured
> with storage compatibility mode {{CASSANDRA_4}}. However, this also means
> peers are unable to use messaging {{VERSION_51}}, so some of the guarantees
> around consistency and visibility of metadata changes are weakened as these
> depend on encoding metadata epochs in internode messages. Those limitations
> aside, the cluster can be operated as normal following the upgrade with
> schema and topology changes permitted. The effects of these changes persist
> through a downgrade. The downgrade requires operators to manually remove some
> directories on disk, but can be done online without taking down the entire
> cluster.
> -There's one problem with this at the moment; in trunk an extra identifier is
> included in gossip digest syn messages to help guard against split brain
> scenarios when intialising a new cluster. Running with {{CASSANDRA_4}}
> compatibility currently causes the checking of this identifier to error which
> prevents the CMS being initialised (via {{nodetool cms initialize}}) during
> the 5.1 upgrade.- edit: this is no longer an issue
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
