[
https://issues.apache.org/jira/browse/CASSANDRA-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140224#comment-13140224
]
T Jake Luciani commented on CASSANDRA-3428:
-------------------------------------------
That's not what I'm saying.
When "incremental_backup: true" then sstables are hard linked you end up with a
directory full of sstables including ones that have been compacted into newer
versions of the data.
If you want to restore from a backup in this scenario you need to load all the
sstables then compact.
If we had constituent data stored in the sstables of what sstables were used to
create them then you could programmatically figure out what sstables we need to
use to get a complete optimal snapshot.
It would also be handy to track this information anyway in the case of
corruption of a sstable you could inspect the meta-data and get the list of
sstables to retrieve from backup to fix *just* the corrupt file.
> 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
