Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 86607 invoked from network); 22 Mar 2011 16:29:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 22 Mar 2011 16:29:06 -0000 Received: (qmail 27360 invoked by uid 500); 22 Mar 2011 16:29:04 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 27329 invoked by uid 500); 22 Mar 2011 16:29:04 -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 27319 invoked by uid 99); 22 Mar 2011 16:29:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Mar 2011 16:29:04 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sdolgy@gmail.com designates 209.85.216.44 as permitted sender) Received: from [209.85.216.44] (HELO mail-qw0-f44.google.com) (209.85.216.44) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Mar 2011 16:28:58 +0000 Received: by qwg5 with SMTP id 5so6138156qwg.31 for ; Tue, 22 Mar 2011 09:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=H2GghlGkRaAR09deUseWXIejOraKPCNNcexu/TMz0Zk=; b=g20C4xSdVOCraYmtFN9ZsnunffqJFoPr6/+mK7GEc9KjOZgyfsD0WPXGuIWxLOa/4x hHhQjzTM+DbIyMS5/ink+6QHN6hiAjg0zxMj2Jq57hPthY4anT2tGfmZeBdz3bwdDO9S xRbtdRqJnIhPVXH4BnMHFlc/n7wHXw9PO2Cco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=STGJZLqrl2qRK2W3juEZJqa5zvWhrCRt24Tm4sTus4SZCKo8v2jiubV7cTKfNnpXrH CgTe3sOHrR6i735DUXY4pYN1ys0XWpDY1pqrnKWaz2CyoFdirZ9YDKg6ih+YoguiAfaQ rWINb+51Vf8vJBc6Ia5eGeSXk8Ipe02Yy9kVE= MIME-Version: 1.0 Received: by 10.229.206.42 with SMTP id fs42mr4906777qcb.150.1300811317819; Tue, 22 Mar 2011 09:28:37 -0700 (PDT) Received: by 10.229.110.1 with HTTP; Tue, 22 Mar 2011 09:28:36 -0700 (PDT) Received: by 10.229.110.1 with HTTP; Tue, 22 Mar 2011 09:28:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Mar 2011 17:28:36 +0100 Message-ID: Subject: Re: Ec2Snitch & Other snitches... From: Sasha Dolgy To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=0016e68ee29d84b875049f14bc83 --0016e68ee29d84b875049f14bc83 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the good response. my thought was as aws becomes more and more expensive (no option to swap out small cheap disks for larger cheap disks...) i'll need to switch to dedicated hardware and the topology will change. didnt want to back myself into a corner early on when the amount of data is still manageable. -sd On Mar 22, 2011 5:05 PM, "Robert Coli" wrote: > On Tue, Mar 22, 2011 at 7:19 AM, Sasha Dolgy wrote: >> More, I suppose the question I'm after is, can the snitch method be >> adjusted adhoc (with node restart) or once it's changed from >> SimpleSnitch to Ec2Snitch that's it? > > You can change Snitches on a cluster with data on it, as long as you > are very careful about what you are doing and you are in a particular > case which you are probably not in if you want to change your Snitch. > > The snitch meaningfully determines replica placement strategy, and in > general when changing snitches you need the replica placement strategy > to stay exactly the same. Unfortunately the point of changing a snitch > is usually.. changing your replica placement strategy. Simplest case > is if the replica placement strategy actually stays the same, like for > example when Digg replaced its custom version of the > PropertyFileSnitch with SimpleSnitch in prep for going single-DC, > because we weren't actually using the functionality of PFS. In that > case, I simply generated a set of input which hashed correctly such > that I had one piece of input per node. I then verified the topology > based on this input before and after changing my snitch, and got the > same results both times, confirming that my change of the Snitch was a > no-op. > > A less simple, but still tractable case is if the topology changes > such that one or more replicas is different but at least one is still > the same. In this case, repair would be likely to repair.. most.. of > your data. But honestly if you have to change strategy that much (and > are not running IP-partitioned counts, which make this operation much > more difficult) you probably just want to dump and reload your data > into a new cluster which has the topology and snitch you want. > > =Rob --0016e68ee29d84b875049f14bc83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks for the good response.=A0

my thought was as aws becomes more and more expensive (no option to swap= out small cheap disks for larger cheap disks...) i'll need to switch t= o dedicated hardware and the topology will change.=A0 didnt want to back my= self into a corner early on when the amount of data is still manageable.

-sd

On Mar 22, 2011 5:05 PM, "Robert Coli"= <rcoli@digg.com> wrote:
> On Tue, Mar 22, 2011 at 7:19 AM, Sasha Dolgy <sdolgy@gmail.com> wrote:
>> More, I suppose the question I'm after is, can the snitch meth= od be
>> adjusted adhoc (with node restart) or once it's chang= ed from
>> SimpleSnitch to Ec2Snitch that's it?
>
> You can change Snitches on a cluster with data on it, as long as you> are very careful about what you are doing and you are in a particula= r
> case which you are probably not in if you want to change your Sni= tch.
>
> The snitch meaningfully determines replica placement strategy= , and in
> general when changing snitches you need the replica placem= ent strategy
> to stay exactly the same. Unfortunately the point of c= hanging a snitch
> is usually.. changing your replica placement strategy. Simplest case> is if the replica placement strategy actually stays the same, like f= or
> example when Digg replaced its custom version of the
> Pro= pertyFileSnitch with SimpleSnitch in prep for going single-DC,
> because we weren't actually using the functionality of PFS. In tha= t
> case, I simply generated a set of input which hashed correctly su= ch
> that I had one piece of input per node. I then verified the topo= logy
> based on this input before and after changing my snitch, and got the> same results both times, confirming that my change of the Snitch was= a
> no-op.
>
> A less simple, but still tractable case = is if the topology changes
> such that one or more replicas is different but at least one is still<= br>> the same. In this case, repair would be likely to repair.. most.. o= f
> your data. But honestly if you have to change strategy that much = (and
> are not running IP-partitioned counts, which make this operation much<= br>> more difficult) you probably just want to dump and reload your data=
> into a new cluster which has the topology and snitch you want.
>
> =3DRob
--0016e68ee29d84b875049f14bc83--