[
https://issues.apache.org/jira/browse/CASSANDRA-12659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15499215#comment-15499215
]
Wei Deng commented on CASSANDRA-12659:
--------------------------------------
Can you reliably reproduce this problem? If yes, it would be very helpful if
you describe the repro steps so that somebody can take a closer look.
BTW, "there are no tombstones left" doesn't mean you're safe. You may have run
into a typical ["zombie
resurrection"|http://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html]
situation when the system cleared up all of the tombstones.
> Query in reversed order brough back deleted data
> ------------------------------------------------
>
> Key: CASSANDRA-12659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12659
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 3.0.5, 6 nodes cluster
> Reporter: Tai Khuu Tan
>
> We have and issues with our Cassandra 3.0.5. After we deleted a large amount
> of data in the multiple partition keys. Query those partition keys with
> reversed order on a clustering key return the deleted data. I have checked
> and there are no tombstones left. All of them are deleted. So I don't know
> where or how can those deleted data still exist. Is there any other place
> that Cassandra will read data when query in reverse order compare to normal
> order ?
> the schema is very simple
> {noformat}
> CREATE TABLE table ( uid varchar, version timestamp, data1 varchar, data2
> varchar, data3 varchar, data4 varchar, data5 varchar, PRIMARY KEY (uid,
> version, data1 , data2 , data3 , data4 ) ) with compact storage;
> {noformat}
> Query are doing reverse order on column timestamp
> Ex:
> {noformat}
> select * from data where uid="uid1" order by version DESC
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
