[
https://issues.apache.org/jira/browse/CASSANDRA-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700046#comment-14700046
]
Jonathan Ellis commented on CASSANDRA-9917:
-------------------------------------------
bq. It only affects the decision to write a hint in the first place (down for
long than the window? stop writing hints)... 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.
True, but let me clarify: if no node in the cluster is down for longer than max
hint window, and you have no hardware failures, and you have batch commitlog
enabled, then you won't need repair. Fair?
I don't really see a difference vs min_batchlog_ttl. Especially since Paulo
independently came up with the same value we use as default max hint window
here.
Let's not offer users more tuning knobs than they can meaningfully distinguish
between.
> 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)
