[
https://issues.apache.org/jira/browse/CASSANDRA-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14701115#comment-14701115
]
Paulo Motta commented on CASSANDRA-9917:
----------------------------------------
There are 3 possible failure scenarios we want to protect against, by limiting
the {{gc_grace_seconds}} of tables involved in a batchlog/MV:
1. batchlog reaching the destination node alive (< 1s)
2. protect against minor spikes and gc pauses (few minutes)
3. medium to major outages (> 1h)
By using a large treshold we can protect against 1-3, but we can't define the
optimal value (since this varies from cluster to cluster) nor use
{{max_hints_windows_in_ms}} (due to the valid reasons given by Alexey). By
validating that the value is not {{0}}, we only protect against 1, and users
might workaround this limitation by setting the gc_grace_seconds to 1, which
can still lead to problems.
I think 2 is pretty common and can save us some headache in the future, so how
about using a min treshold of 10 minutes to protect against 1 and 2? We can
either hard code this, or leave the unpublished property
{{cassandra.min_batchlog_ttl}} if advanced operators want to modify that
constant. We can still properly document the effects of gc gs in the MV
documentation to protect against 3.
> 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)
