[
https://issues.apache.org/jira/browse/CASSANDRA-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696852#comment-14696852
]
Aleksey Yeschenko commented on CASSANDRA-9917:
----------------------------------------------
{{max_hint_window_in_ms}} is misunderstood by almost everyone, it seems.
It only affects the decision to write a hint in the first place (down for long
than the window? stop writing hints).
1) Batchlog ignores {{max_hint_window_in_ms}} and always writes its hints, no
matter what, if a node is down
2) {{max_hint_window_in_ms}} does not affect replay decisions - it's ignored on
replay - only gc gs - turned into ttl - matters
It's most often true that if a node has been down for longer than
{{max_hint_window_in_mx}}, it is going to have data missing, yes. But there are
no guarantees that it being down for shorter than that means it doesn't. Any
number of nodes with hints for the target node could go down for a time longer
than hints' expiration time, die forever, lose their hints - you name it.
And many outright disable hints (batchlog would still write them), or have
ridiculously low {{max_hint_window_in_ms}}.
What I'm saying is that I don't like tying any correctness logic to
{{max_hint_window_in_ms}} param.
> 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.0 rc1
>
>
> 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)
