Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0FCFEDBA1 for ; Wed, 26 Sep 2012 07:04:05 +0000 (UTC) Received: (qmail 79612 invoked by uid 500); 26 Sep 2012 07:04:02 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 79593 invoked by uid 500); 26 Sep 2012 07:04:02 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 79576 invoked by uid 99); 26 Sep 2012 07:04:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Sep 2012 07:04:02 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FSL_RCVD_USER,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of goudarzi@gmail.com designates 209.85.212.44 as permitted sender) Received: from [209.85.212.44] (HELO mail-vb0-f44.google.com) (209.85.212.44) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Sep 2012 07:03:55 +0000 Received: by vbbfc26 with SMTP id fc26so298932vbb.31 for ; Wed, 26 Sep 2012 00:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OQP2CthH2AQ5CpPdmkLSBZmnpy3P+EWS/2fN7R+3BCs=; b=DnGk7+ahZv/3J03WLwX8QejQANpbdlnHhxgp2+RzFuJBQp5WDTDndfYIW58VAxJz9V iCik+Ftq7jK+7Rrs3vUAH9qEHa6azG4LI5s6HXIzykdrCp/dLpjekh5ky/yTPjK0AhrL +HXbqYFsg7XFo/j6ylUDiTtAC2VGhyJVYs9rlEguTWJgctbudvL7uaCQsi5Mb34W1Ncj 2XkXL0IO+UT6HGTUdS/P8Nl182IeL7Xs2ClyWlQVbmg3yi1nPbWMZjeQzV0SwzqDO0AH pSAfTQsy2/wLA/b4wdFbHxMfZPxouQZnVxUBhtYhNaUzkOV34ylPhkuwsj8pz9Ao2tZQ 193Q== MIME-Version: 1.0 Received: by 10.52.72.164 with SMTP id e4mr933305vdv.103.1348643014697; Wed, 26 Sep 2012 00:03:34 -0700 (PDT) Received: by 10.58.125.105 with HTTP; Wed, 26 Sep 2012 00:03:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Sep 2012 00:03:34 -0700 Message-ID: Subject: Re: 1.1.5 Missing Insert! Strange Problem From: Arya Goudarzi To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=bcaec501654dd1e1e004ca956b15 X-Virus-Checked: Checked by ClamAV on apache.org --bcaec501654dd1e1e004ca956b15 Content-Type: text/plain; charset=UTF-8 No. We don't use TTLs. On Tue, Sep 25, 2012 at 11:47 PM, Roshni Rajagopal < roshni_rajagopal@hotmail.com> wrote: > By any chance is a TTL (time to live ) set on the columns... > > ------------------------------ > Date: Tue, 25 Sep 2012 19:56:19 -0700 > Subject: 1.1.5 Missing Insert! Strange Problem > From: goudarzi@gmail.com > To: user@cassandra.apache.org > > > Hi All, > > I have a 4 node cluster setup in 2 zones with NetworkTopology strategy and > strategy options for writing a copy to each zone, so the effective load on > each machine is 50%. > > Symptom: > I have a column family that has gc grace seconds of 10 days (the default). > On 17th there was an insert done to this column family and from our > application logs I can see that the client got a successful response back > with write consistency of ONE. I can verify the existence of the key that > was inserted in Commitlogs of both replicas however it seams that this > record was never inserted. I used list to get all the column family rows > which were about 800ish, and examine them to see if it could possibly be > deleted by our application. List should have shown them to me since I have > not gone beyond gc grace seconds if this record was deleted during past > days. I could not find it. > > Things happened: > During the same time as this insert was happening, I was performing a > rolling upgrade of Cassandra from 1.1.3 to 1.1.5 by taking one node down at > a time, performing the package upgrade and restarting the service and going > to the next node. I could see from system.log that some mutations were > replayed during those restarts, so I suppose the memtables were not flushed > before restart. > > > Could this procedure cause the row inser to disappear? How could I > troubleshoot as I am running out of ideas. > > Your help is greatly appreciated. > > > Cheers, > =Arya > --bcaec501654dd1e1e004ca956b15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No. We don't use TTLs.

On Tue, Sep 25= , 2012 at 11:47 PM, Roshni Rajagopal <roshni_rajagopal@hotmail.= com> wrote:
By any chance is a TTL (time to live ) set on the columns...


Date: Tue, 25 Sep 2012 19:56:19 -0700
Subject: 1.1.5 Missin= g Insert! Strange Problem
From: goudarzi@gmail.com
To: user@cas= sandra.apache.org


Hi All,

<= div>I have a 4 node cluster setup in 2 zones with NetworkTopology strategy = and strategy options for writing a copy to each zone, so the effective load= on each machine is 50%.

Symptom:
I have a column family that has gc grace seconds of 10 d= ays (the default). On 17th there was an insert done to this column family a= nd from our application logs I can see that the client got a successful res= ponse back with write consistency of ONE. I can verify the existence of the= key that was inserted in Commitlogs of both replicas however it seams that= this record was never inserted. I used list to get all the column family r= ows which were about 800ish, and examine them to see if it could possibly b= e deleted by our application. List should have shown them to me since I hav= e not gone beyond gc grace seconds if this record was deleted during past d= ays. I could not find it.=C2=A0

Things happened:
During the same time as this= insert was happening, I was performing a rolling upgrade of Cassandra from= 1.1.3 to 1.1.5 by taking one node down at a time, performing the package u= pgrade and restarting the service and going to the next node. I could see f= rom system.log that some mutations were replayed during those restarts, so = I suppose the memtables were not flushed before restart.=C2=A0


Could this procedure cause the row inser= to disappear? How could I troubleshoot as I am running out of ideas.
=

Your help is greatly appreciated.


Cheers,
=3DArya
=

--bcaec501654dd1e1e004ca956b15--