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 CAAF9DBAC for ; Wed, 29 Aug 2012 09:39:49 +0000 (UTC) Received: (qmail 27628 invoked by uid 500); 29 Aug 2012 09:39:47 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 27609 invoked by uid 500); 29 Aug 2012 09:39:47 -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 27587 invoked by uid 99); 29 Aug 2012 09:39:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2012 09:39:46 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=FSL_RCVD_USER,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a82.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2012 09:39:39 +0000 Received: from homiemail-a82.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a82.g.dreamhost.com (Postfix) with ESMTP id C7FAD282060 for ; Wed, 29 Aug 2012 02:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thelastpickle.com; h=from :content-type:message-id:mime-version:subject:date:references:to :in-reply-to; s=thelastpickle.com; bh=AvVLgZHfiW5iztEKxNkyLcNyYs I=; b=X4GolVygCHmpdi7UOQyNMtPAmptUG1pw0DYeU7lUtgtMNBlWIfzt1VRKuh qixw8DfVWby53b49BAeZED4bLhm/FWvNtjuAjdHACuEUj+CMYbmMtJs7aPg3BkcH X7YtIbzlkt8bQ13aq1W+sEjz6iLgc6fgmqNFAgUpNWoVyMnew= Received: from [172.16.1.10] (unknown [203.86.207.101]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aaron@thelastpickle.com) by homiemail-a82.g.dreamhost.com (Postfix) with ESMTPSA id 9117328205F for ; Wed, 29 Aug 2012 02:39:15 -0700 (PDT) From: aaron morton Content-Type: multipart/alternative; boundary="Apple-Mail=_669ABD55-5907-4390-9156-8307AFCF24C5" Message-Id: <88B82A1C-5B1E-4F5C-923E-B53FC5868D71@thelastpickle.com> Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Subject: Re: Automating nodetool repair Date: Wed, 29 Aug 2012 21:39:07 +1200 References: <503C0853.2080505@globalrelay.net> <503D2D27.40208@globalrelay.net> To: user@cassandra.apache.org In-Reply-To: X-Mailer: Apple Mail (2.1486) --Apple-Mail=_669ABD55-5907-4390-9156-8307AFCF24C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Staggering the repairs also gives the DynamicSnitch a chance to route = around nodes which maybe running slow. Cheers ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 29/08/2012, at 11:19 AM, Omid Aladini wrote: >>> Secondly, what's the need for sleep 120? >>=20 >> just give the cluster a chance to settle down between repairs... >> there's no real need for it, just is there "because". >=20 > Actually, repair could cause unreplicated data to be streamed and new > sstables to be created. New sstables could cause pending compactions > and increase the potential number of sstables a row could be spread > across. Therefore you might need more disk seeks to read a row and > have slower read response time. If the read response time is critical, > it's a good idea to wait for pending compactions to settle before > repairing other neighbouring ranges that overlap replicas. >=20 > -- Omid >=20 >> -- >> Aaron Turner >> http://synfin.net/ Twitter: @synfinatic >> http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix = & >> Windows >> Those who would give up essential Liberty, to purchase a little = temporary >> Safety, deserve neither Liberty nor Safety. >> -- Benjamin Franklin >> "carpe diem quam minimum credula postero" --Apple-Mail=_669ABD55-5907-4390-9156-8307AFCF24C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
http://www.thelastpickle.com
On 29/08/2012, at 11:19 AM, Omid Aladini <omidaladini@gmail.com> = wrote:

Secondly, what's the need for sleep = 120?

just give the cluster a chance to settle down = between repairs...
there's no real need for it, just is there = "because".

Actually, repair could cause unreplicated = data to be streamed and new
sstables to be created. New sstables = could cause pending compactions
and increase the potential number of = sstables a row could be spread
across. Therefore you might need more = disk seeks to read a row and
have slower read response time. If the = read response time is critical,
it's a good idea to wait for pending = compactions to settle before
repairing other neighbouring ranges that = overlap replicas.

-- Omid

--
Aaron Turner
http://synfin.net/ =         Twitter: = @synfinatic
http://tcpreplay.synfin.net/ - = Pcap editing and replay tools for Unix &
Windows
Those who = would give up essential Liberty, to purchase a little = temporary
Safety, deserve neither Liberty nor Safety.
=    -- Benjamin Franklin
"carpe diem quam minimum = credula = postero"

= --Apple-Mail=_669ABD55-5907-4390-9156-8307AFCF24C5--