Have you confirmed that your clocks are all synced in the cluster? This may be the result of an unintentional read-repair occurring if that were the case.
-Nate On Tue, Apr 27, 2010 at 2:20 PM, Joost Ouwerkerk <jo...@openplaces.org> wrote: > Hmm... Even after deleting with cl.ALL, I'm getting data back for some > rows after having deleted them. Which rows return data is > inconsistent from one run of the job to the next. > > On Tue, Apr 27, 2010 at 1:44 PM, Joost Ouwerkerk <jo...@openplaces.org> wrote: >> To check that rows are gone, I check that KeySlice.columns is empty. And as >> I mentioned, immediately after the delete job, this returns the expected >> number. >> Unfortunately I reproduced with QUORUM this morning. No node outages. I am >> going to try ALL to see if that changes anything, but I am starting to >> wonder if I'm doing something else wrong. >> On Mon, Apr 26, 2010 at 9:45 PM, Jonathan Ellis <jbel...@gmail.com> wrote: >>> >>> How are you checking that the rows are gone? >>> >>> Are you experiencing node outages during this? >>> >>> DC_QUORUM is unfinished code right now, you should avoid using it. >>> Can you reproduce with normal QUORUM? >>> >>> On Sat, Apr 24, 2010 at 12:23 PM, Joost Ouwerkerk <jo...@openplaces.org> >>> wrote: >>> > I'm having trouble deleting rows in Cassandra. After running a job that >>> > deletes hundreds of rows, I run another job that verifies that the rows >>> > are >>> > gone. Both jobs run correctly. However, when I run the verification >>> > job an >>> > hour later, the rows have re-appeared. This is not a case of "ghosting" >>> > because the verification job actually checks that there is data in the >>> > columns. >>> > >>> > I am running a cluster with 12 nodes and a replication factor of 3. I >>> > am >>> > using DC_QUORUM consistency when deleting. >>> > >>> > Any ideas? >>> > Joost. >>> > >>> >>> >>> >>> -- >>> Jonathan Ellis >>> Project Chair, Apache Cassandra >>> co-founder of Riptano, the source for professional Cassandra support >>> http://riptano.com >> >> >