[
https://issues.apache.org/jira/browse/CASSANDRA-8356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14238404#comment-14238404
]
Aleksey Yeschenko commented on CASSANDRA-8356:
----------------------------------------------
[~philipthompson] Philip, could you please try to repro? With counters and with
regular columns.
Create a supercolumn table on 1.2, write a bunch of data in the same pattern as
in the ticket, flush them all (and save somewhere). Upgrade the node to 2.0
without upgrading the sstables, and try the same queries - see if everything is
still there.
Thanks.
> Slice query on a super column family with counters doesn't get all the data
> ---------------------------------------------------------------------------
>
> Key: CASSANDRA-8356
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8356
> Project: Cassandra
> Issue Type: Bug
> Reporter: Nicolas Lalevée
> Assignee: Aleksey Yeschenko
> Fix For: 2.0.12
>
>
> We've finally been able to upgrade our cluster to 2.0.11, after
> CASSANDRA-7188 being fixed.
> But now slice queries on a super column family with counters doesn't return
> all the expected data. We first though because of all the trouble we had that
> we lost data, but there a way to actually get the data, so nothing is lost;
> it just that cassandra seems to incorrectly skip it.
> See the following CQL log:
> {noformat}
> cqlsh:Theme> desc table theme_view;
> CREATE TABLE theme_view (
> key bigint,
> column1 varint,
> column2 text,
> value counter,
> PRIMARY KEY ((key), column1, column2)
> ) WITH COMPACT STORAGE AND
> bloom_filter_fp_chance=0.010000 AND
> caching='KEYS_ONLY' AND
> comment='' AND
> dclocal_read_repair_chance=0.000000 AND
> gc_grace_seconds=864000 AND
> index_interval=128 AND
> read_repair_chance=1.000000 AND
> replicate_on_write='true' AND
> populate_io_cache_on_flush='false' AND
> default_time_to_live=0 AND
> speculative_retry='99.0PERCENTILE' AND
> memtable_flush_period_in_ms=0 AND
> compaction={'class': 'SizeTieredCompactionStrategy'} AND
> compression={'sstable_compression': 'SnappyCompressor'};
> cqlsh:Theme> select * from theme_view where key = 99421 limit 10;
> key | column1 | column2 | value
> -------+---------+------------+-------
> 99421 | -12 | 2011-03-25 | 59
> 99421 | -12 | 2011-03-26 | 5
> 99421 | -12 | 2011-03-27 | 2
> 99421 | -12 | 2011-03-28 | 40
> 99421 | -12 | 2011-03-29 | 14
> 99421 | -12 | 2011-03-30 | 17
> 99421 | -12 | 2011-03-31 | 5
> 99421 | -12 | 2011-04-01 | 37
> 99421 | -12 | 2011-04-02 | 7
> 99421 | -12 | 2011-04-03 | 4
> (10 rows)
> cqlsh:Theme> select * from theme_view where key = 99421 and column1 = -12
> limit 10;
> key | column1 | column2 | value
> -------+---------+------------+-------
> 99421 | -12 | 2011-03-25 | 59
> 99421 | -12 | 2014-05-06 | 15
> 99421 | -12 | 2014-06-06 | 7
> 99421 | -12 | 2014-06-10 | 22
> 99421 | -12 | 2014-06-11 | 34
> 99421 | -12 | 2014-06-12 | 35
> 99421 | -12 | 2014-06-13 | 26
> 99421 | -12 | 2014-06-14 | 16
> 99421 | -12 | 2014-06-15 | 24
> 99421 | -12 | 2014-06-16 | 25
> (10 rows)
> {noformat}
> As you can see the second query should return data from 2012, but it is not.
> Via thrift, we have the exact same bug.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
