cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Motta (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9917) MVs should validate gc grace seconds on the tables involved
Date Tue, 18 Aug 2015 11:36:46 GMT


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

View raw message