[
https://issues.apache.org/jira/browse/CASSANDRA-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-3428.
---------------------------------------
Resolution: Not A Problem
Fix Version/s: (was: 1.1)
bq. You are saying I should cron snapshot the cluster then keep the incremental
between
Yes. This is standard backup procedure. Doing periodic full snapshots both
gives you an upper bound on how many incrementals you have to apply (which, as
you point out, can certainly contain information that is obsoleted later) and
gives you extra redundancy in case of corruption of one of the incrementals
(which otherwise becomes increasingly likely as time goes by).
bq. I think with the feature I'm suggesting this wouldn't be necessary and IMO
be less data to backup in the end
I don't think it's worth it. It would only be useful for the "restore to most
recent possible time" and nothing earlier, because otherwise you have the "data
mixed in from newer sstables in the compacted version" problem.
Additionally, at least one person has implemented map/reduce against snapshots,
which is another point in favor of a "periodic full + incrementals" approach.
(I'll go bug him again about contributing a patch, now that I remember it...)
> 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
>
> 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
