[
https://issues.apache.org/jira/browse/CASSANDRA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15328411#comment-15328411
]
Paulo Motta commented on CASSANDRA-8928:
----------------------------------------
bq. The primary use case for downgrading sstables is to abort an upgrade. So
for example, if you're on 2.1 and want to go to 2.2 or 3.x, the upgrade plan
often includes a contingency plan to abort and revert back to the older
version, including preserving data written while in the upgraded version.
The same end result can be achieved, although with maybe a bit more of work, by
backing up sstables of the upgraded node and wiping/recreating the node in a
previous version, and then use sstableloader of the newer version to reload the
data in the recreated node, which would be easily enabled by CASSANDRA-8110.
Although standalone downgrading could be nice, I'm not sure it's really worth
the effort and risk of carrying sstable writing code across multiple versions.
bq. Would it be possible to limit the implementation of this to the core
sstable data file? We could then have an offline downgrade sstable process that
would convert to the older sstable data file and those files could be bulk
loaded through that version's sstable loader into the reverted cluster.
This is more or less the approach I'm proposing, but instead of doing an
offline downgrade only of the data file + sstableloading afterwards, you would
only need to use sstableloader of the newer version to load newer version
sstables in the reverted cluster automatically. Wouldn't this be sufficient?
> Add downgradesstables
> ---------------------
>
> Key: CASSANDRA-8928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8928
> Project: Cassandra
> Issue Type: New Feature
> Components: Tools
> Reporter: Jeremy Hanna
> Assignee: Kaide Mu
> Priority: Minor
> Labels: gsoc2016, mentor
>
> As mentioned in other places such as CASSANDRA-8047 and in the wild,
> sometimes you need to go back. A downgrade sstables utility would be nice
> for a lot of reasons and I don't know that supporting going back to the
> previous major version format would be too much code since we already support
> reading the previous version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
