cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9917) MVs should validate gc grace seconds on the tables involved
Date Mon, 17 Aug 2015 20:58:48 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700217#comment-14700217
] 

Aleksey Yeschenko commented on CASSANDRA-9917:
----------------------------------------------

I'm going to be a pedant and bring up another example, just because: you have nodes A and
B, A has some hints/batches for B; A is down for 1.5 hours, then A comes up, but B goes down
for 1.5 hours. No single node has been down for longer than max hint window, but, assuming
gc gs/max hints window of 3 hours, none of the batches or hints have survived. You need repair.
And with current MVs - to drop and recreate the MV?

What I'm saying is that whatever we do, it's going to be broken. Also that {{max_hints_window_in_ms}}
should not be part of any calculations whatsoever, as you can ultimately infer nothing from
it.

So let's just validate that it's not set to {{0}} and properly document the effects of gc
gs in the MV documentation.

> MVs should validate gc grace seconds on the tables involved
> -----------------------------------------------------------
>
>                 Key: CASSANDRA-9917
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9917
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Aleksey Yeschenko
>            Assignee: Paulo Motta
>              Labels: materializedviews
>             Fix For: 3.0 beta 2
>
>
> For correctness reasons (potential resurrection of dropped values), batchlog entries
are TTLs with the lowest gc grace second of all the tables involved in a batch.
> It means that if gc gs is set to 0 in one of the tables, the batchlog entry will be dead
on arrival, and never replayed.
> We should probably warn against such LOGGED writes taking place, in general, but for
MVs, we must validate that gc gs on the base table (and on the MV table, if we should allow
altering gc gs there at all), is never set too low, or else.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message