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 206A49F28 for ; Wed, 11 Apr 2012 18:52:26 +0000 (UTC) Received: (qmail 56222 invoked by uid 500); 11 Apr 2012 18:52:23 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 56181 invoked by uid 500); 11 Apr 2012 18:52:23 -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 56172 invoked by uid 99); 11 Apr 2012 18:52:23 -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 18:52:23 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a56.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Apr 2012 18:52:18 +0000 Received: from homiemail-a56.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a56.g.dreamhost.com (Postfix) with ESMTP id 395EEFE064 for ; Wed, 11 Apr 2012 11:51:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=thelastpickle.com; h=from :mime-version:content-type:subject:date:in-reply-to:to :references:message-id; q=dns; s=thelastpickle.com; b=yiE/p1vHoA 6eF/f9PCu/xG4zfCpi/3/6jq4CwO7tDZwqrKkbv778KPAbzk9rrEMp5dS3PSEWt8 l+Tuvr1gZedkjaDVl4ONN2eih5omczISpRoqY3ykOBM7zfKBUMRi2G07AIhRRSAq mbrqjVz61Dd0ThIpqpIZC9OEUylJGQpgY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thelastpickle.com; h=from :mime-version:content-type:subject:date:in-reply-to:to :references:message-id; s=thelastpickle.com; bh=uy0Z47EE6QygqS+l Z3v+wc6Nl84=; b=gGouqW/BUHlKNRqZgQTYPcXGAs0BW0a9L4LlzyJzQXAXeDU0 C3Q1ZwToIaYySZoZC0KYk4wUxLiecfSHXglfKBfAJsGHiIFLX50LuNlkQa7OcVYY xRJef3cQr5h2ffGydoMoNbcRxeEMjgxP25ltTKo6dQUqOzxeOM0sSM+h5MA= Received: from [172.16.1.3] (125-236-193-159.adsl.xtra.co.nz [125.236.193.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aaron@thelastpickle.com) by homiemail-a56.g.dreamhost.com (Postfix) with ESMTPSA id 74FEBFE06B for ; Wed, 11 Apr 2012 11:51:57 -0700 (PDT) From: aaron morton Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_F42404FA-58C8-439D-997C-A6E49E3F0BFD" Subject: Re: need of regular nodetool repair Date: Thu, 12 Apr 2012 06:51:53 +1200 In-Reply-To: <4F854A87.3090108@4friends.od.ua> To: user@cassandra.apache.org References: <4F8544D6.6090108@4friends.od.ua> <4F854868.5010902@4friends.od.ua> <4F854A87.3090108@4friends.od.ua> Message-Id: X-Mailer: Apple Mail (2.1257) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_F42404FA-58C8-439D-997C-A6E49E3F0BFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 HH in 1.X+ is very good, but it is still an optimisation for achieving = consistency.=20 >> So I expect that even if I loose some HH then some other replica will = reply with data. Is it correct? Run a repair and see.=20 Cheers ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 11/04/2012, at 9:10 PM, Igor wrote: > On 04/11/2012 12:04 PM, ruslan usifov wrote: >>=20 >> HH - this is hinted handoff? >>=20 > Yes >=20 >> 2012/4/11 Igor >> On 04/11/2012 11:49 AM, R. Verlangen wrote: >>=20 >> Not everything, just HH :) >>=20 >> 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? >>=20 >> Hope this works for me, but can not work for others.=20 >>=20 >>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>=20 >>> On 04/11/2012 11:34 AM, ruslan usifov wrote: >>>>=20 >>>> Sorry fo my bad english, so QUORUM allow doesn't make repair = regularity? But form your anser it does not follow >>>>=20 >>>> 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. >>>>=20 >>>> This is also what's in the manual = http://wiki.apache.org/cassandra/Operations#Repairing_missing_or_inconsist= ent_data (point 2) >>>>=20 >>>>=20 >>>> 2012/4/11 ruslan usifov >>>> Hello >>>>=20 >>>> 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)=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> With kind regards, >>>>=20 >>>> Robin Verlangen >>>> www.robinverlangen.nl >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> With kind regards, >>>=20 >>> Robin Verlangen >>> www.robinverlangen.nl >>>=20 >>=20 >>=20 >=20 --Apple-Mail=_F42404FA-58C8-439D-997C-A6E49E3F0BFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 HH in = 1.X+ is very good, but it is still an optimisation for achieving = consistency. 

So I expect that even if I loose = some HH then some other replica will reply with data.  Is it = correct?
Run a = repair and see. 

Cheers

http://www.thelastpickle.com

On 11/04/2012, at 9:10 PM, Igor wrote:

=20 =20
On 04/11/2012 12:04 PM, ruslan usifov wrote:
HH - this is hinted handoff?

Yes

2012/4/11 Igor <igor@4friends.od.ua>
=
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 <igor@4friends.od.ua>
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 <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  http://wiki.apache.org/cassandra/Operations#Repairing_mi= ssing_or_inconsistent_data (point 2)


2012/4/11 ruslan usifov <ruslan.usifov@gmail.com>
= 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





= --Apple-Mail=_F42404FA-58C8-439D-997C-A6E49E3F0BFD--