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