incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Lebresne <sylv...@datastax.com>
Subject Re: reducing disk usage advice
Date Tue, 15 Mar 2011 09:14:41 GMT
On Mon, Mar 14, 2011 at 8:17 PM, Karl Hiramoto <karl@hiramoto.org> wrote:
> On 03/14/11 15:33, Sylvain Lebresne wrote:
>>
>> CASSANDRA-1537 is probably also a partial but possibly sufficient
>> solution. That's also probably easier than CASSANDRA-1610 and I'll try
>> to give it a shot asap, that had been on my todo list way too long.
>>
> Thanks, eager to see CASSANDRA-1610 someday.   What  I've been doing the
> last day has been multiple restarts across the cluster when one node's
> data/ dir gets to 150GB.  restarting cassandra brings the nodes data/
> directory down to around 60GB, I see cassandra deleteing a lot of
> SSTables on startup.

This is because cassandra lazily remove the compacted files. You don't have to
restart a node though, you can just trigger a full java GC through
jconsole and this
should remove the files.

>
> One question,  since I use a TTL is it safe to set GCGraceSeconds  to 0?   I don't
manually delete ever, I just rely on the TTL for deletion, so are forgotten deletes an issue?
>
>
>> The rule is this. Say you think that m is a reasonable value for
>> GCGraceSeconds. That is, you make sure that you'll always put back up
>> failing nodes and run repair within m seconds. Then, if you always use
>> a TTL of n (in your case 24 hours), the actual GCGraceSeconds that you
>> should set is m - n.
>>
>> So putting a GCGrace of 0 in you would would be roughly equivalent to
>> set a GCGrace of 24h on a "normal" CF. That's probably a bit low.
>>
> What do you mean by "normal"?  If I were to set GCGrace to 0 would  risk
> data corruption?  Wouldn't setting GCGrace to 0 help reduce disk space
> pressure?

Actually, if you really only use TTL on that column family and you
always set the
same TTL, it's ok to set a GCGrace of 0.
If you don't always put the same TTL, the kind of scenario that could
happen are this:
  - you insert a column with ttl=24h.
  - after 3h, you overwrite the column with a ttl of 2h.
At that point, you expect that you have updated the column ttl so that
it will only leave
2 hours. However, if you have GCGrace=0 and you are unlucky enough that a node
got the first insert but not the second one, and stay dead for more
than 2h, then when
you put it back up, it will not receive anything related to the second
insert, because
the column has expired and no tombstone has been created for it (since
GCGrace=0) and
thus the initial column will reappear (for a few hours but still). If
you have a bigger value
for GCGrace, then when the failing node is back up, it will receive a
tombstone about
the second insert and thus will not make the first insert reappear.

So the rule is, if you never lower down the TTL of a column (expanding
it is fine), you can
safely set GCGrace to 0.

Mime
View raw message