cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-11087) Queries on compact storage tables in mixed version clusters can return incorrect results
Date Mon, 01 Feb 2016 15:30:39 GMT

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

Sylvain Lebresne commented on CASSANDRA-11087:
----------------------------------------------

Mostly lgtm but a few remarks (the 1st one matter, the 2 others are nits really):
* Pretty sure we only need to add this for compact tables (in fact, compact static ones since
that's the only kind that can have statics) so it. In fact, for non-compact tables, {{metadata.compactValueColumn()}}
returns {{null}} and I suspect that might be a problem.
* Style wise, I'd prefer brackets for the {{else}} part of the modified {{if}} condition since
the {{then}} part has some.
* Might be worth a small comment as to why we need this (if only to link back to this issue).

> Queries on compact storage tables in mixed version clusters can return incorrect results
> ----------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-11087
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11087
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Coordination
>            Reporter: Sam Tunnicliffe
>            Assignee: Sam Tunnicliffe
>             Fix For: 3.0.x, 3.x
>
>
> Whilst writing a dtest for CASSANDRA-11045, it becomes apparent that queries on compact
storage tables are broken during the 3.0 upgrade (and this has probably been the case since
day 1). 
> tl;dr In a cluster with a mix of < 3.0 and 3.0 nodes, reads on COMPACT STORAGE tables
may not include all results. 
> To repro: tables are created and data written before any nodes are upgraded to 3.0+,
some nodes are then upgraded putting the cluster into a mixed state.
> Now, when a query is run where the coordinator is a < 3.0 node, any 3.0+ replica which
has not yet run upgradesstables always returns 0 results.  Once upgradesstables is run, the
replica returns the correct results. Likewise, if the data is inserted after the node is upgraded,
the results are correct. If the 3.0 node acts as the coordinator, the results are also correct
and so once all nodes are upgraded, the problem goes away.
> The behaviour can be seen for both single partition and range requests as [this dtest|https://github.com/beobal/cassandra-dtest/commit/91bb9ffd8fb761ad3454187d2f05f05a6e7af930]
demonstrates.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message