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 396D61042E for ; Thu, 1 Aug 2013 21:08:22 +0000 (UTC) Received: (qmail 37755 invoked by uid 500); 1 Aug 2013 21:08:19 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 37727 invoked by uid 500); 1 Aug 2013 21:08:19 -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 37719 invoked by uid 99); 1 Aug 2013 21:08:19 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Aug 2013 21:08:19 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rcoli@eventbrite.com designates 209.85.216.44 as permitted sender) Received: from [209.85.216.44] (HELO mail-qa0-f44.google.com) (209.85.216.44) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Aug 2013 21:08:15 +0000 Received: by mail-qa0-f44.google.com with SMTP id hu16so28276qab.17 for ; Thu, 01 Aug 2013 14:07:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=lHWbGvfbJcYYYeCRjEqdB6kybFH3GZ9yvQVaG3DisOo=; b=hadCMfoZGI8Ofbnh0cK/uBruk2Z+aChmlREOZgL0910Wxb9pHe2cM100OS6hD4l/sT lcgrseT8oMh+Ejl+7dtdOKRI6fWzIEe9OMG5fmXT1Qf8kpXytNUv3/NR0kUzzqKrG09z XqtCmnaSsoELMMTJeL8K+oEYLK9Q8wEaI5YwjWQFcuBjg7CRohqZhu2ejUjAal8Uwnw1 ggz2zNwIKp00FJBhfHh21hmEMyHTAgZDX5kMBf8u7qWUoFewH4oJUkAJyaLJLXJRZosA YR0Ox/s5PA/x1c6AuPgd5oMytXWKoV4UBHgW74dJozZxts3UONUu0pL9MSHHuPujGOwt g4kQ== MIME-Version: 1.0 X-Received: by 10.49.0.170 with SMTP id 10mr4906576qef.3.1375391274598; Thu, 01 Aug 2013 14:07:54 -0700 (PDT) Received: by 10.49.72.133 with HTTP; Thu, 1 Aug 2013 14:07:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Aug 2013 14:07:54 -0700 Message-ID: Subject: Re: How often to run `nodetool repair` From: Robert Coli To: "user@cassandra.apache.org" Content-Type: multipart/alternative; boundary=047d7b33d45259976204e2e93c71 X-Gm-Message-State: ALoCoQlmZor0YQs/oGUcMERu4UhyZhyR9O84Q7k9k4ebLfjxv3GlUCQJkl0rG6nNPvLEEbzV1qQ6 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b33d45259976204e2e93c71 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 1, 2013 at 1:16 PM, Andrey Ilinykh wrote: > > On Thu, Aug 1, 2013 at 12:26 PM, Robert Coli wrote: > >> TTL is effectively DELETE; you need to run a repair once every >> gc_grace_seconds. If you don't, data might un-delete itself. >> > > How is it possible? Every replica has TTL, so it when it expires every > replica has tombstone. I don't see how you can get data with no tombstone. > What do I miss? > I knew I had heard of cases where repair is required despite TTL, but didn't recall the specifics. Thanks for the opportunity to go look it up... http://comments.gmane.org/gmane.comp.db.cassandra.user/21008 quoting Sylvain Lebresne : " The initial question was about "can I use inserting with ttl=1 instead of issuing deletes", ***so that would be a case where you do shadow a previous version with a very small ttl and so repair is important.*** (EMPHASIS rcoli) But you're right that if you only issue data with expiration (no deletes) and that you * either do not overwrite columns * or are sure that when you do overwrite, the value you're overwriting has a ttl that is lesser or equal than the ttl of the value you're overwriting with (+gc_grace to be precise) then yes, ***repair is not necessary because you can't have shadowed value resurfacing.*** (EMPHASIS rcoli) " So, to be more precise with my initial statement : "TTL is like DELETE in some cases, so unless you are certain that you are not (and will not be) in those cases, you should run repair when using TTL." Also you will be unable to repair entire keyspaces, you will have to repair on a per column family basis, manually excluding CFs matching these criteria, increasing management complexity. =Rob --047d7b33d45259976204e2e93c71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 1, 2013 at 1:16 PM, Andrey Ilinykh <ailiny= kh@gmail.com> wrote:

On Thu, Aug 1, 2013 at 12:26 PM, Robert Coli <rcoli@eventbrite.com> wrote:
TTL is effectively DELETE; you need to run a repair once every gc_grac= e_seconds. If you don't, data might un-delete itself.=A0

How is it possible? Every replica has TTL, so it when it expires= every replica has tombstone. I don't see how you can get data with no = tombstone. What do I miss?

I knew I had heard of cases where repair is required despi= te TTL, but didn't recall the specifics. Thanks for the opportunity to = go look it up...


quoting Sylvain Lebresne :
"
The initial questi= on was about "can I use inserting with ttl=3D1 instead of
issuing d= eletes", ***so that would be a case where you do shadow a previous
version with a very small ttl and so repair is important.*** (EMPHASIS rcol= i)

But you're right that if you only issue data with expiration = (no deletes) and
that you
=A0 * either do not overwrite columns
=A0 * or are sure that when you do overwrite, the value you're overwrit= ing has
=A0 =A0 =A0a ttl that is lesser or equal than the ttl of the val= ue you're
overwriting with
=A0 =A0 =A0(+gc_grace to be precise)then yes, ***repair is not necessary because you can't have shadowed = value
resurfacing.*** (EMPHASIS rcoli)
"
=
So, to be more precise with my i= nitial statement :=A0

"TTL is like DELETE in some cases, so unless you are certain that you = are not (and will not be) in those cases, you should run repair when using = TTL."

Also you will be unable to repair entire keyspaces, you will have to repair= on a per column family basis, manually excluding CFs matching these criter= ia, increasing management complexity.

=3DRob
--047d7b33d45259976204e2e93c71--