Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <r2ia17e13e71004271435w2ba90b14xeb52179f7173b3f3@mail.gmail.com>
References: <m2x775e31411004241023h7a79739o2834870c16976190@mail.gmail.com>
	 <r2se06563881004261845v2e1c6dcdrd2b8aa407794733e@mail.gmail.com>
	 <i2z775e31411004271044wf387a006ha564ac18d6245a08@mail.gmail.com>
	 <h2p775e31411004271420zabde269ct7905419a45724ea@mail.gmail.com>
	 <r2ia17e13e71004271435w2ba90b14xeb52179f7173b3f3@mail.gmail.com>
Date: Tue, 27 Apr 2010 17:37:58 -0400
Message-ID: <w2w775e31411004271437hb07da656o12d477084d188663@mail.gmail.com>
Subject: Re: Cassandra reverting deletes?
From: Joost Ouwerkerk <joost@openplaces.org>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Clocks are in sync:

cluster04:~/cassandra$ dsh -g development "date"
Tue Apr 27 17:36:33 EDT 2010
Tue Apr 27 17:36:33 EDT 2010
Tue Apr 27 17:36:33 EDT 2010
Tue Apr 27 17:36:33 EDT 2010
Tue Apr 27 17:36:34 EDT 2010
Tue Apr 27 17:36:34 EDT 2010
Tue Apr 27 17:36:34 EDT 2010
Tue Apr 27 17:36:34 EDT 2010
Tue Apr 27 17:36:34 EDT 2010
Tue Apr 27 17:36:35 EDT 2010
Tue Apr 27 17:36:35 EDT 2010
Tue Apr 27 17:36:35 EDT 2010

On Tue, Apr 27, 2010 at 5:35 PM, Nathan McCall <nate@vervewireless.com> wro=
te:
> 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 <joost@openplaces.org> w=
rote:
>> Hmm... Even after deleting with cl.ALL, I'm getting data back for some
>> rows after having deleted them. =A0Which 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 <joost@openplaces.org> =
wrote:
>>> To check that rows are gone, I check that KeySlice.columns is empty. =
=A0And as
>>> I mentioned, immediately after the delete job, this returns the expecte=
d
>>> number.
>>> Unfortunately I reproduced with QUORUM this morning. =A0No node outages=
. =A0I 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 <jbellis@gmail.com> wro=
te:
>>>>
>>>> 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 <joost@openplaces.or=
g>
>>>> wrote:
>>>> > I'm having trouble deleting rows in Cassandra.=A0 After running a jo=
b that
>>>> > deletes hundreds of rows, I run another job that verifies that the r=
ows
>>>> > are
>>>> > gone.=A0 Both jobs run correctly.=A0 However, when I run the verific=
ation
>>>> > job an
>>>> > hour later, the rows have re-appeared.=A0 This is not a case of "gho=
sting"
>>>> > because the verification job actually checks that there is data in t=
he
>>>> > columns.
>>>> >
>>>> > I am running a cluster with 12 nodes and a replication factor of 3.=
=A0 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
>>>
>>>
>>
>