[
https://issues.apache.org/jira/browse/CASSANDRA-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140236#comment-13140236
]
Jonathan Ellis commented on CASSANDRA-3428:
-------------------------------------------
bq. If you want to restore from a backup in this scenario you need to load all
the sstables then compact
I'm still confused: the snapshot files plus incrementals from after the last
full snapshot (up to point-in-time, if desired) give you exactly what you want,
no more, no less. None of the incrementals can be compacted into sstables in
the snapshot because by construction we've said the snapshot is older. (And if
we have a newer snapshot... use that one instead.)
If you're trying to do a "partial" snapshot restore (i.e. not removing all the
existing sstable files first) that won't work in the general case because
you're unlikely to end up with sstables containing exactly the set of
incremental sstables you want with no other data mixed in.
> add constituent tracking to sstables
> ------------------------------------
>
> Key: CASSANDRA-3428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3428
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: T Jake Luciani
> Labels: compaction
> Fix For: 1.1
>
>
> Compaction merges older sstables into newer versions of the data.
> When snapshotting sstables (esp incrementally) it would be very useful to
> know what older sstables are no longer needed because they are now
> represented in a newer version.
> This patch should add the list of sstables that made up each new sstable and
> store this info in the -Statistics file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
