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 7C9631013A for ; Thu, 1 Aug 2013 20:16:44 +0000 (UTC) Received: (qmail 3060 invoked by uid 500); 1 Aug 2013 20:16:42 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 3031 invoked by uid 500); 1 Aug 2013 20:16:42 -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 3023 invoked by uid 99); 1 Aug 2013 20:16:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Aug 2013 20:16:42 +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 (nike.apache.org: domain of ailinykh@gmail.com designates 209.85.217.181 as permitted sender) Received: from [209.85.217.181] (HELO mail-lb0-f181.google.com) (209.85.217.181) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Aug 2013 20:16:36 +0000 Received: by mail-lb0-f181.google.com with SMTP id o10so1871117lbi.12 for ; Thu, 01 Aug 2013 13:16:15 -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=qGA9hlXcR4K0nfBe7MfrZSWIvC6hvqQmPPwy+GNmrPc=; b=lzmnsSsHn6mNqITGX/o7P8oi6/SeaiaPGMRcIZmS9yIJ7s96CqOb6Jdm43rDABHwMR p1a9qLbjMDUfIzVqOO1QjmTCrH9qqkeT141xh7lUtXlWY5/D00xOkWzIaj/bsUPQJkc6 fM65JzVZr5a5d3hCw6LZixgsiWB4RZKeHySJem/VQ5MLRPDGP5HWMGjffDHtgRxmH6Rj lJ2KWevYLIXZsY/08N2xjUFJYuRPrYX1tZb+QQjB2u14UPI1Ck6Qpdd1IjkcU8sLhUFs xQXb2Gi7Z7iLKFJL+0lPr3yH38rrzW8n/Tj7hf3g49lZCAVk94jbKkKCLvhA0C+CC7+S yyDw== MIME-Version: 1.0 X-Received: by 10.152.163.101 with SMTP id yh5mr1587575lab.9.1375388175854; Thu, 01 Aug 2013 13:16:15 -0700 (PDT) Received: by 10.114.180.230 with HTTP; Thu, 1 Aug 2013 13:16:15 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Aug 2013 13:16:15 -0700 Message-ID: Subject: Re: How often to run `nodetool repair` From: Andrey Ilinykh To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001a113369a6a6733a04e2e883d9 X-Virus-Checked: Checked by ClamAV on apache.org --001a113369a6a6733a04e2e883d9 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 1, 2013 at 12:26 PM, Robert Coli wrote: > On Thu, Aug 1, 2013 at 9:35 AM, Carl Lerche wrote: > >> I read in the docs that `nodetool repair` should be regularly run unless >> no delete is ever performed. In my app, I never delete, but I heavily use >> the ttl feature. Should repair still be run regularly? Also, does repair >> take less time if it is run regularly? If not, is there a way to >> incrementally run it? It seems that when I do run repair, it takes a long >> time and causes high amounts CPU usage and iowait. >> > > 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? Andrey --001a113369a6a6733a04e2e883d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 1, 2013 at 12:26 PM, Robert Coli <= rcoli@eventbrite.= com> wrote:
On Thu, A= ug 1, 2013 at 9:35 AM, Carl Lerche <me@carllerche.com> wrote= :
I read in the docs that `nodetool re= pair` should be regularly run unless no delete is ever performed. In my app= , I never delete, but I heavily use the ttl feature. Should repair still be= run regularly? Also, does repair take less time if it is run regularly? If= not, is there a way to incrementally run it? It seems that when I do run r= epair, it takes a long time and causes high amounts CPU usage and iowait.

TTL is effectively DELETE; you= need to run a repair once every gc_grace_seconds. If you don't, data m= ight 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 tombst= one. What do I miss?

Andrey=A0

--001a113369a6a6733a04e2e883d9--