[
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)
