cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Eriksson (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6958) upgradesstables does not maintain levels for existing SSTables
Date Tue, 01 Apr 2014 05:48:15 GMT


Marcus Eriksson commented on CASSANDRA-6958:

agree, i have quite a few changes to these classes pending in CASSANDRA-6696, I'd prefer to
do any bigger refactoring after that is in (will create ticket)

> upgradesstables does not maintain levels for existing SSTables
> --------------------------------------------------------------
>                 Key: CASSANDRA-6958
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Wei Deng
>            Assignee: Marcus Eriksson
>             Fix For: 2.0.7
>         Attachments: 0001-Use-6958-v2.patch, 0001-Use-LeveledCompactionTask-for-upgradesstables-when-L.patch
> Initially ran into this issue on a DSE 3.2 (C* 1.2) to DSE 4.0 (C* 2.0) upgrade, and
then I was able to reproduce it when testing an upgrade from C* 2.0.5 to C* 2.1-beta so the
problem still exists in the latest code.
> Basically after you've upgraded to the new version and run "nodetool upgradesstables"
on a CF/table that has been using LCS, then all of the non-L0 SSTables will be changed to
L0 in the upgraded SSTables. In other words, they don't maintain their level and will have
to go through the compaction again. The problem is that if you've got thousands of non-L0
SSTables before the upgrade, then all of these files showing up in L0 will push the system
to do STCS and start to build some huge L0 tables. If a user doesn't budget enough free space
(for example, if they used the recommended guideline and only budgeted 10% of free space because
LCS is in use), then this STCS in L0 effect will have them run out of space.

This message was sent by Atlassian JIRA

View raw message