[ 
https://issues.apache.org/jira/browse/CASSANDRA-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699692#comment-14699692
 ] 

Paulo Motta commented on CASSANDRA-9917:
----------------------------------------

bq. 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 want a min-batchlog-ttl to account at least for network delay + 
min-batchlog-replay-period but that can also protect from small transient 
failures, so I think 1-3 hours must be sufficient without restricting 
{{gc_grace_seconds}} too much.

I made the default 3 hours, but the operator can decrease it if necessary by 
setting the {{cassandra.min_batchlog_ttl}} system property.

Updated patch 
[link|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:9917-3.0]
 with new version. Dtests available 
[here|https://github.com/riptano/cassandra-dtest/pull/464]

* [3.0 
dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9917-3.0-dtest/]
* [3.0 
testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9917-3.0-testall/]
* [trunk 
dtests|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9917-trunk-dtest/]
* [trunk 
testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-9917-trunk-testall/]

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

Reply via email to