cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shalom Sagges <shal...@liveperson.com>
Subject Re: About Tombstones and TTLs
Date Mon, 19 Dec 2016 14:07:03 GMT
Thanks for the explanation Matija, but fortunately, that I know. Forgot to
mention that I'm using a multi DC cluster.
I'll try to summarize just the questions I have, because my email was
indeed quite long :-)


   - Why setting gc_grace_seconds=0 will disable hints for the table?
   - How can an expired TTL record be deleted by Cassandra without
   tombstoning or compaction? Aren't SSTables immutable files, and expired
   records are removed through compaction?
   - If I only use TTL for deletion, do I still need gc_grace_seconds to be
   bigger than 0?
   - If I only use TTL for deletion, but use updates as well, do I need
   gc_grace_seconds to be bigger than 0?


Thanks!


Shalom Sagges
DBA
T: +972-74-700-4035
<http://www.linkedin.com/company/164748> <http://twitter.com/liveperson>
<http://www.facebook.com/LivePersonInc> We Create Meaningful Connections



On Mon, Dec 19, 2016 at 2:39 PM, Matija Gobec <matija0204@gmail.com> wrote:

> Hi,
>
> gc_grace_seconds is used to maintain data consistency in some failure
> scenarios. When manually deleting data that action creates tombstones which
> are kept for that defined period before being compacted. If one of the
> replica nodes is down while deleting data and it gets back up after the
> gc_grace_seconds defined period your previously delete data will reappear
> (ghost data). As it is stated in datastax documentation on a single node
> you can set gc_grace_seconds to 0 and you can do the same for tables that
> contain only data with TTL. In the mentioned failure scenario your downed
> node will have data with TTL information and no data inconsistency will
> happen.
>
> On Mon, Dec 19, 2016 at 1:00 PM, Shalom Sagges <shaloms@liveperson.com>
> wrote:
>
>> Hi Everyone,
>>
>> I was reading a blog on TWCS by Alex Dejanovski from The Last Pickle (
>> http://thelastpickle.com/blog/2016/12/08/TWCS-part1.html)
>>
>> When I got to the comments section, I didn't understand why setting
>> gc_grace_seconds to 0 will disable hints for the associated table:
>> *"It is a very good point that gc_grace_seconds shouldn't be lowered too
>> much as its impact on hinted handoff is not a well known fact, and using a
>> value of 0 will purely disable hints on the table."*
>>
>> When I tried to read some more about deletes and TTLs, I got to a
>> Datastax documentation https://docs.datastax.com/en/cassandra/3.0/cas
>> sandra/dml/dmlAboutDeletes.html
>> stating the following:
>>
>> *Cassandra allows you to set a default_time_to_live property for an
>> entire table. Columns and rows marked with regular TTLs are processed as
>> described above; but when a record exceeds the table-level TTL, Cassandra
>> deletes it immediately, without tombstoning or compaction.*
>>
>> Which got me a bit more confused.
>> So I hope someone can shed some light on some questions I've got:
>>
>>
>>    - Why setting gc_grace_seconds=0 will disable hints for the table?
>>    - How can an expired TTL record be deleted by Cassandra without
>>    tombstoning or compaction? Aren't SSTables immutable files, and expired
>>    records are removed through compaction?
>>    - If I only use TTL for deletion, do I still need gc_grace_seconds to
>>    be bigger than 0?
>>    - If I only use TTL for deletion, but use updates as well, do I need
>>    gc_grace_seconds to be bigger than 0?
>>
>>
>> Sorry for all those questions, I'm just really confused from all the
>> TTL/tombstones subject (still a newbie).
>>
>> Thanks a lot!
>>
>>
>> Shalom Sagges
>> DBA
>> T: +972-74-700-4035 <+972%2074-700-4035>
>> <http://www.linkedin.com/company/164748> <http://twitter.com/liveperson>
>> <http://www.facebook.com/LivePersonInc> We Create Meaningful Connections
>>
>>
>>
>> This message may contain confidential and/or privileged information.
>> If you are not the addressee or authorized to receive this on behalf of
>> the addressee you must not use, copy, disclose or take action based on this
>> message or any information herein.
>> If you have received this message in error, please advise the sender
>> immediately by reply email and delete this message. Thank you.
>>
>
>

-- 
This message may contain confidential and/or privileged information. 
If you are not the addressee or authorized to receive this on behalf of the 
addressee you must not use, copy, disclose or take action based on this 
message or any information herein. 
If you have received this message in error, please advise the sender 
immediately by reply email and delete this message. Thank you.

Mime
View raw message