[
https://issues.apache.org/jira/browse/CASSANDRA-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218693#comment-13218693
]
Chris Herron commented on CASSANDRA-3710:
-----------------------------------------
Adding notes from discussion on #cassandra-dev:
There are legitimate production use cases that would benefit from being able to
skip snapshots, both for truncate *and* dropColumnFamily.
For example, our application has some ColumnFamilies that contain important
data, and others that contain large volumes of derived data. Relatively often,
we have the need to discard the derived data in order to recompute it. Truncate
without snapshot would be ideal for this.
While we could proactively prune snapshots, the coordination of such
housekeeping out-of-process is complex. Differentiating "important" snapshots
from unwanted snapshots when pruning requires that this process has knowledge
of our domain model.
Brandon stressed that the current philosophy is that Cassandra should never
truly delete data, as a protection against accidental data loss. My own opinion
is that Cassandra and its API should not work against the caller's intent.
A compromise that we talked about is as follows:
1. Additional methods for truncate and dropColumnFamily that include a snapshot
control flag, e.g:
truncate(String keySpace, String cf, boolean withSnapshot)
dropColumnFamily(String keySpace, String cf, boolean withSnapshot)
2. Add a "safety" configuration option that governs whether the snapshot flag
is actually honored.
So if(!withSnapshot && !allowSkippedSnapshotOnDeletion), we could either fail
hard for an illegal request or log a warning and snapshot anyway.
The advantage of this approach is that it would be equally useful for testing
and production. The disadvantage is that it is an API change and so would have
to come in a later release.
An interim solution might be to add the configuration option (e.g.
allowSkippedSnapshotOnDeletion, default false) and have truncate
and delete honor that value directly. In a later release, the "withSnapshot"
API additions could use allowSkippedSnapshotOnDeletion as described above in #2.
> Add a configuration option to disable snapshots
> -----------------------------------------------
>
> Key: CASSANDRA-3710
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3710
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Brandon Williams
> Fix For: 1.0.9
>
> Attachments: Cassandra107Patch_TestModeV1.txt
>
>
> Let me first say, I hate this idea. It gives cassandra the ability to
> permanently delete data at a large scale without any means of recovery.
> However, I've seen this requested multiple times, and it is in fact useful in
> some scenarios, such as when your application is using an embedded cassandra
> instance for testing and need to truncate, which without JNA will timeout
> more often than not.
--
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
