[
https://issues.apache.org/jira/browse/CASSANDRA-5137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549448#comment-13549448
]
Sylvain Lebresne commented on CASSANDRA-5137:
---------------------------------------------
bq. Should we just say that for 1.1 we'll retain all sstables
For 1.1, I'd suggest doing my fourth pseudo-solution above, i.e. moving the
renaming of newly created writes at the end of the compaction (it's trivial).
Then at startup, we could indeed retain all sstables for normal CF, but for
counter we would keep removing the predecessors as we do now. It wouldn't
totally fix the risk of losing counters, but it would make it very unlikely
(you'd need to fail exactly in the middle of the bulk renaming a newly create
sstable writers), while just retaining all sstables would make it very easy to
have overcounts.
For 1.2, you compaction_log solution does seem reasonable.
> Make sure SSTables left over from compaction get deleted and logged
> -------------------------------------------------------------------
>
> Key: CASSANDRA-5137
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5137
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 1.1.3
> Reporter: Yuki Morishita
> Assignee: Yuki Morishita
> Priority: Minor
> Fix For: 1.1.9, 1.2.1
>
> Attachments: 5137-1.1.txt
>
>
> When opening ColumnFamily, cassandra checks SSTable files' ancestors and
> skips loading already compacted ones. Those files are expected to be deleted,
> but currently that never happens.
> Also, there is no indication of skipping loading file in the log, so it is
> confusing especially doing upgradesstables.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
