[
https://issues.apache.org/jira/browse/CASSANDRA-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783994#comment-17783994
]
Andres de la Peña commented on CASSANDRA-19007:
-----------------------------------------------
[~maedhroz] Thanks, I don't really know yet how to solve the issue. Differently
from 8272/8273, here the coordinator doesn't get any hints to detect the
scenario.
The only approach that comes to mind is applying replica filtering only on one
of the columns and doing the rest of the filtering on the coordinator, after
reconciliation. But that would be very expensive.
Alternatively, we might want to exploit that the conflictive rows are those
where some of the filtered columns are either absent or have different
timestamps. So the replica might return those partial hits, only rejecting rows
where all the filtered columns are present, have the same timestamp, and don't
satisfy the filter. Then the coordinator would filter the false positives after
reconciliation. I'm unsure if that covers all the possible cases, and it would
also have a significant performance cost.
I'm not working on this one now, so feel free to take the ticket if you have
time and/or any ideas on how to approach it.
> Queries with multi-column replica-side filtering can miss rows
> --------------------------------------------------------------
>
> Key: CASSANDRA-19007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19007
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
> Reporter: Andres de la Peña
> Priority: Normal
>
> {{SELECT}} queries with multi-column replica-side filtering can miss rows if
> the filtered columns are spread across out-of-sync replicas. This dtest
> reproduces the issue:
> {code:java}
> @Test
> public void testMultiColumnReplicaSideFiltering() throws IOException
> {
> try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
> KEY, a int, b int)"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
> VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
> VALUES (0, 2)"));
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b =
> 2 ALLOW FILTERING");
> Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> }
> {code}
> This edge case affects queries using {{ALLOW FILTERING}} or any index
> implementation.
> It affects all branches since multi-column replica-side filtering queries
> were introduced, long before 3.0.
> The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
> case, since it only solves single-column conflicts where stale rows could
> resurrect. This bug however doesn't resurrect data, it can only miss rows
> while the replicas are out-of-sync.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
