[
https://issues.apache.org/jira/browse/CASSANDRA-15897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280656#comment-17280656
]
Ekaterina Dimitrova edited comment on CASSANDRA-15897 at 2/7/21, 8:50 PM:
--------------------------------------------------------------------------
* 3.0 version reviewed(Thanks to [~blerer]!) and more or less ready (depends on
[~brandon.williams] 's opinion as he agreed also to review it, thank you!)
* It seems that upgradesstables works in 3.0 but not in 3.11 (lb SSTables are
still presented after upgradesstables run), I corrected the version in
CASSANDRA-16295
* With this patch we ensure the lowest SSTables version to be past 3.0 but we
don't guarantee that the SSTables will be upgraded to the last possible version
for all 3.0 and 4.0 version C* nodes, which was the idea of CASSANDRA-16063
where we added the local check. This seems to me as a change of intention which
I don't think it will be an issue as soon as:
** We guarantee the old pre-V3 SSTables are not presented anymore
** The minimal support for compact storage is removed with the next version
* Since 4.0 cannot even read the lb SSTables, do we need a check at all when
we drop compact storage or we would expect that there won't be already any that
old SSTables on a cluster with 4.0 nodes?
And last but not least, is this a 4.0 blocker? I started doubting it. Any
opinion will be highly appreciated.
was (Author: e.dimitrova):
* 3.0 version reviewed(Thanks to [~blerer]!) and more or less ready (depends on
[~brandon.williams] 's opinion as he agreed also to review it, thank you!)
* It seems that upgradesstables works in 3.0 but not in 3.11 (lb SSTables are
still presented after upgradesstables run), I corrected the version in
CASSANDRA-16295
* With this patch we ensure the lowest SSTables version to be past 3.0 but we
don't guarantee that the SSTables will be upgraded to the last possible version
for all 3.0 and 4.0 version C* nodes, which was the idea of CASSANDRA-16063
where we added the local check. This seems to me as a change of intention which
I don't think it will be an issue as soon as:
** We guarantee the old pre-V3 SSTables are not presented anymore
** The minimal support for compact storage is removed with the next version
* Since 4.0 cannot even read the lb SSTables, do we need a check at all when
we drop compact storage or we would expect that there won't be already any that
old SSTables on a cluster with 4.0 nodes?
And last but not least, is this a 4.0 blocker? I started doubting it. Any
opinion will be highly appreciated.
> Dropping compact storage with 2.1-sstables on disk make them unreadable
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-15897
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15897
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
> Reporter: Marcus Eriksson
> Assignee: Ekaterina Dimitrova
> Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> Test reproducing:
> https://github.com/krummas/cassandra/commits/marcuse/dropcompactstorage
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
