[
https://issues.apache.org/jira/browse/CASSANDRA-8273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15266427#comment-15266427
]
Robert Stupp commented on CASSANDRA-8273:
-----------------------------------------
{{ALLOW FILTERING}} cannot provide _any_ consistency guarantee, since even
{{ONE}} could end up on a replica with stale data - but that's the expected
behavior for CL {{ONE}}.
I think the point that may confuse people, is that {{ALLOW FILTERING}} +
{{QUORUM}} doesn't really respect the CL.
Maybe it's worth to add a warning, if CL > {{ONE}} is used with {{ALLOW
FILTERING}}. WDYT?
With CL {{ONE}} + {{ALLOW FILTERING}} _and_ partition (or token) restriction,
it shouldn't make a (big) difference where the filtering takes place. But for
filtering queries w/ 2i (or no partition/token restriction) it could make a
huge difference.
Maybe we can use replica filtering for CL {{ONE}} and coordinator filtering
otherwise. OTOH, as you said, it makes the code path more complex.
(PS: Strike my last comment.)
> Allow filtering queries can return stale data
> ---------------------------------------------
>
> Key: CASSANDRA-8273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8273
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sylvain Lebresne
>
> Data filtering is done replica side. That means that a single replica with
> stale data may make the whole query return that stale data.
> For instance, consider 3 replicas A, B and C, and the following situation:
> {noformat}
> CREATE TABLE test (k int PRIMARY KEY, v1 text, v2 int);
> CREATE INDEX ON test(v1);
> INSERT INTO test(k, v1, v2) VALUES (0, 'foo', 1);
> {noformat}
> with every replica up to date. Now, suppose that the following queries are
> done at {{QUORUM}}:
> {noformat}
> UPDATE test SET v2 = 2 WHERE k = 0;
> SELECT * FROM test WHERE v1 = 'foo' AND v2 = 1;
> {noformat}
> then, if A and B acknowledge the insert but C respond to the read before
> having applied the insert, then the now stale result will be returned. Let's
> note that this is a problem related to filtering, not 2ndary indexes.
> This issue share similarity with CASSANDRA-8272 but contrarily to that former
> issue, I'm not sure how to fix it. Obviously, moving the filtering to the
> coordinator would remove that problem, but doing so would, on top of not
> being trivial to implmenent, have serious performance impact since we can't
> know in advance how much data will be filtered and we may have to redo query
> to replica multiple times.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
