[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cassandra-user
Subject:    Re: Coordination of expired TTLs compared to tombstones
From:       Tyler Hobbs <tyler () datastax ! com>
Date:       2015-05-29 18:56:00
Message-ID: CAAam9ssi5UF_SQiqszBpibMLE7Cp=_vA2pQQt3SUux6xrxvsOg () mail ! gmail ! com
[Download RAW message or body]

On Fri, May 29, 2015 at 1:31 PM, Robert Wille <rwille@fold3.com> wrote:

>
> I was wondering how that compares to cells with expired TTLs. Does the
> node get to skip sending data back to the coordinator for an expired TTL?


No, it has to send expired cells.


>
> Suppose you wrote a cell with no TTL, and then updated it with a TTL.
> Suppose that node 1 got both writes, but node 2 only got the first one. If
> you asked for the cell after it expired, and node 1 did not send anything
> to the coordinator, it seems to me that that could violate consistency
> levels. Also, read repair could never fix node 2. So, how does that work?
>

That's precisely why they have to be sent to the coordinator.


>
> On a related note, do cells with expired TTLs have to wait
> gc_grace_seconds before they can be compacted out?


Yes.


> It seems to me that if they could get compacted out immediately after
> expiration, you could get zombie data, just like you can with tombstones.
> For example, write a cell with no TTL to all replicas, shut down one
> replica, update the cell with a TTL, compact after the TTL has expired,
> then bring the other node back up. Voila, the formerly down node has a
> value that will replicate to the other nodes.


Correct, that's why they can't be purged immediately.


-- 
Tyler Hobbs
DataStax <http://datastax.com/>

[Attachment #3 (text/html)]

<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 29, \
2015 at 1:31 PM, Robert Wille <span dir="ltr">&lt;<a href="mailto:rwille@fold3.com" \
target="_blank">rwille@fold3.com</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><br> I was wondering how that compares to cells with expired \
TTLs. Does the node get to skip sending data back to the coordinator for an expired \
TTL?</blockquote><div><br></div><div>No, it has to send expired cells.<br></div><div> \
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> <br>
Suppose you wrote a cell with no TTL, and then updated it with a TTL. Suppose that \
node 1 got both writes, but node 2 only got the first one. If you asked for the cell \
after it expired, and node 1 did not send anything to the coordinator, it seems to me \
that that could violate consistency levels. Also, read repair could never fix node 2. \
So, how does that work?<br></blockquote><div><br></div><div>That&#39;s precisely why \
they have to be sent to the coordinator.<br></div><div>  </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>
On a related note, do cells with expired TTLs have to wait gc_grace_seconds before \
they can be compacted out?</blockquote><div><br></div><div>Yes.<br></div><div>  \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> It seems to me that if they could get compacted out \
immediately after expiration, you could get zombie data, just like you can with \
tombstones. For example, write a cell with no TTL to all replicas, shut down one \
replica, update the cell with a TTL, compact after the TTL has expired, then bring \
the other node back up. Voila, the formerly down node has a value that will replicate \
to the other nodes.</blockquote></div><br></div><div class="gmail_extra">Correct, \
that&#39;s why they can&#39;t be purged immediately.<br></div><div \
class="gmail_extra"><br clear="all"><br>-- <br><div class="gmail_signature"><font \
color="#888888">Tyler Hobbs<span></span><br> <a href="http://datastax.com/" \
target="_blank">DataStax</a><br></font></div> </div></div>



[prev in list] [next in list] [prev in thread] [next in thread]