[
https://issues.apache.org/jira/browse/CASSANDRA-9018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14377851#comment-14377851
]
Maxim Podkolzine commented on CASSANDRA-9018:
---------------------------------------------
I see, thanks for clarification. Here's I find misleading here:
- The two settings are obviously conflicting. I personally find
gc_grace_seconds option a better choice, because it gives a sense of control: I
can decide the expiration of my data, per table on top of that.
- More general: there are several notions dealing with the same problem: grace
period, snapshot and backup. In such cases conflicts often arise.
- Strong recommended settings ("auto_snapshot: true") require an operator to
monitor the disk space. It seems more convenient if Cassandra takes care of its
own space.
- The log doesn't give enough information about what's going on.
Can advise the proper settings for our case: it's perfectly normal that the
data is dropped, and it should be kept _just in case_ for some period? When
needed we do a full backup ourselves. Are there any potential problems with
"auto_snapshot: false"?
> Dropped keyspace is not collected
> ---------------------------------
>
> Key: CASSANDRA-9018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9018
> Project: Cassandra
> Issue Type: Bug
> Reporter: Maxim Podkolzine
> Attachments: cassandra-log.zip
>
>
> As far as I understand when a keyspace is dropped, the data is marked as
> tombstone. We expect that after the grace period (all tables are created with
> gc_grace_seconds=7200), this data is automatically removed during the
> compaction process, which means that keyspace no longer takes any space on
> disk.
> This is not happening (not after 2 or 24 hours). The log keeps saying "No
> files to compact for user defined compaction", keyspace files remain on disk.
> It's not clear whether Cassandra is still waiting for certain event, or
> decided not to collect the data.
> Is there any setting that I missed? Any clues to figure out from the log,
> what's the current state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
