[
https://issues.apache.org/jira/browse/CASSANDRA-10618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14992589#comment-14992589
]
Jim Witschey commented on CASSANDRA-10618:
------------------------------------------
That's odd; I wouldn't expect that from single-node cluster. What kind of
operations were you running on the cluster prior to this? Have you seen it
consistently, or did it just stop happening after you ran compaction?
Are you able to reproduce it from a clean cluster? That'd help us a lot.
> Read ghost data
> ---------------
>
> Key: CASSANDRA-10618
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10618
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 2.1.2
> Reporter: ZhaoYang
>
> In a table( pk, ck, value) with 1 partition key and 1 clustering key.
> SELECT * FROM table where pk='PK1' AND ck1='CK1' (full primary keys) -> will
> return a row that doesn't appear in range scan query (SELECT * FROM table
> where pk='PK1').
> I tested it with Java Driver 2.1.5 as well as DevCenter. Our environment has
> only 1 node and replication factor 1. It's our development DB, multiple
> developers are accessing it. And we are using client-side timestamp generator.
> If I use nodetool to compact this table, this ghost data will disappear.
> What can be the cause? because of un-order timestamp?
> Thank you very much.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
