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 24CEF9546 for ; Wed, 11 Apr 2012 09:04:40 +0000 (UTC) Received: (qmail 64650 invoked by uid 500); 11 Apr 2012 09:04:37 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 64628 invoked by uid 500); 11 Apr 2012 09:04:37 -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 64613 invoked by uid 99); 11 Apr 2012 09:04:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Apr 2012 09:04:37 +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 ruslan.usifov@gmail.com designates 209.85.161.172 as permitted sender) Received: from [209.85.161.172] (HELO mail-gx0-f172.google.com) (209.85.161.172) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Apr 2012 09:04:33 +0000 Received: by ggmi1 with SMTP id i1so352650ggm.31 for ; Wed, 11 Apr 2012 02:04:12 -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=+p0mafgKESu0LMEOywEShaUj/DdMYthq6c6Pt3mm59c=; b=dV4Ro5Vru2gd/TFGVFirfk/g7i8dvfVlS9gSXSvPeqKtYjEAmxoAwW24LalCDqHzDf CXlJVrvQXC0cgavS/OtMPbHaXEgQqCr8YxwjKB9l43yHhrTMMVmdSl9DV1sN61Jw78Sz g1IQYuC/Px217R7NC+5My/cyBvz/BhvjC8sCvmgjbx+MqvXMdf4vOySWmKmUfmB88/iN m9wgG9tsnSfmAXYvcSQtTa9RqGz0G1ezr5k5KqpzTrG9NCzpjS3D2nBaDexjQwaW48/n yBb6uJ8EYVwDDp+zX/pGwAEcOXdjA8aetZONmYqFqb4sFZRTMOAAbuazg8v4KNjAfX2s /BDg== MIME-Version: 1.0 Received: by 10.236.176.167 with SMTP id b27mr10192548yhm.55.1334135052400; Wed, 11 Apr 2012 02:04:12 -0700 (PDT) Received: by 10.236.145.170 with HTTP; Wed, 11 Apr 2012 02:04:12 -0700 (PDT) In-Reply-To: <4F854868.5010902@4friends.od.ua> References: <4F8544D6.6090108@4friends.od.ua> <4F854868.5010902@4friends.od.ua> Date: Wed, 11 Apr 2012 13:04:12 +0400 Message-ID: Subject: Re: need of regular nodetool repair From: ruslan usifov To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=20cf303f6a22e17a5404bd63859d X-Virus-Checked: Checked by ClamAV on apache.org --20cf303f6a22e17a5404bd63859d Content-Type: text/plain; charset=ISO-8859-1 HH - this is hinted handoff? 2012/4/11 Igor > On 04/11/2012 11:49 AM, R. Verlangen wrote: > > Not everything, just HH :) > > I hope this works for me for the next reasons: I have quite large RF (6 > datacenters, each carry one replica of all dataset), read and write at CL > ONE, relatively small TTL - 10 days, I have no deletes, servers almost > never go down for hour. So I expect that even if I loose some HH then some > other replica will reply with data. Is it correct? > > Hope this works for me, but can not work for others. > > > Well, if everything works 100% at any time there should be nothing to > repair, however with a distributed cluster it would be pretty rare for that > to occur. At least that is how I interpret this. > > 2012/4/11 Igor > >> BTW, I heard that we don't need to run repair if all your data have TTL, >> all HH works, and you never delete your data. >> >> >> On 04/11/2012 11:34 AM, ruslan usifov wrote: >> >> Sorry fo my bad english, so QUORUM allow doesn't make repair regularity? >> But form your anser it does not follow >> >> 2012/4/11 R. Verlangen >> >>> Yes, I personally have configured it to perform a repair once a week, as >>> the GCGraceSeconds is at 10 days. >>> >>> This is also what's in the manual >>> http://wiki.apache.org/cassandra/Operations#Repairing_missing_or_inconsistent_data (point >>> 2) >>> >>> >>> 2012/4/11 ruslan usifov >>> >>>> Hello >>>> >>>> I have follow question, if we Read and write to cassandra claster with >>>> QUORUM consistency level, does this allow to us do not call nodetool repair >>>> regular? (i.e. every GCGraceSeconds) >>>> >>> >>> >>> >>> -- >>> With kind regards, >>> >>> Robin Verlangen >>> www.robinverlangen.nl >>> >>> >> >> > > > -- > With kind regards, > > Robin Verlangen > www.robinverlangen.nl > > > --20cf303f6a22e17a5404bd63859d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable HH - this is hinted handoff?

2012/4/11 Ig= or <igor@4frien= ds.od.ua>
=20 =20 =20
On 04/11/2012 11:49 AM, R. Verlangen wrote:

Not everything, just HH :)

I hope this works for me for the next reasons: I have quite large RF (6 datacenters, each carry one replica of all dataset), read and write at CL ONE, relatively small TTL - 10 days, I have no deletes, servers almost never go down for hour. So I expect that even if I loose some HH then some other replica will reply with data.=A0 Is it correct?

Hope this works for me, but can not work for others.


Well, if everything works 100% at any time th= ere should be nothing to repair, however with a distributed cluster it would be pretty rare for that to occur. At least that is how I interpret this.

2012/4/11 Igor <igor@4friends.od.ua>
BTW, I heard that we don't need to run repair if all your data have TTL, all HH works,=A0 and you never delete your data.


On 04/11/2012 11:34 AM, ruslan usifov wrote:
Sorry fo my bad english, so QUORUM allow=A0 doesn't make repair regularity? But f= orm your anser it does not follow

2012/4/11 R. Verlangen <robin@us2.= nl>
Yes, I personally have configured it to perform a repair once a week, as the GCGraceSeconds is at 10 days.

This is also what's in the manual=A0 http://wiki.apache.org/cassandra/Operations#= Repairing_missing_or_inconsistent_data=A0(point 2)


2012/4/11 ruslan usifov <ruslan.usifov@gmail.com><= /span>
Hello

I have follow question, if we Read and write to cassandra claster with QUORUM consistency level, does this allow to us do not call nodetool repair regular? (i.e. every GCGraceSeconds)



--
With kind regards,

Robin Verlangen






--
With kind regards,

Robin Verlangen



--20cf303f6a22e17a5404bd63859d--