Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 86040 invoked from network); 28 Nov 2010 17:12:24 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 28 Nov 2010 17:12:24 -0000 Received: (qmail 4156 invoked by uid 500); 28 Nov 2010 17:12:21 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 4085 invoked by uid 500); 28 Nov 2010 17:12:21 -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 4077 invoked by uid 99); 28 Nov 2010 17:12:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Nov 2010 17:12:20 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jakers@gmail.com designates 209.85.215.44 as permitted sender) Received: from [209.85.215.44] (HELO mail-ew0-f44.google.com) (209.85.215.44) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Nov 2010 17:12:15 +0000 Received: by ewy8 with SMTP id 8so1709251ewy.31 for ; Sun, 28 Nov 2010 09:11:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=9B7B3xXpDm6BpsFH5wJrDmhtEuodjB5G5f/IYkhYiOA=; b=qMMjE3Eckf9g5oFt+z4QsH9Gh444wZsiG3de9lUMtghMSRJOgtdw2+gHp6n3zG5lcD y/yYPa5balBdHB5xAHPc3W876DDMlBl+tQj2oLQ+jrawgdnKPULK2RKNH/ywOwOr/WDC n/0aqkzDrnj5b1KRRdovR3h3tXKGdE52CNYBs= 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=axaYv+9R5QYa+qfMmcgHMgv0fO7wnyBDzMYH1s7olN/WOT0xZzUvn+g0j9HeHQpzdx UFgue9fGg22t14YZ68nmqMJY9eNKNEjCHev2uCRG96gOGonsVzczbLJDt7ljS4M2Dsy8 jQ3BkHBMDeORaDGgVnWCFnzuAfPIwY7ycjvTI= MIME-Version: 1.0 Received: by 10.213.26.74 with SMTP id d10mr318274ebc.61.1290964313619; Sun, 28 Nov 2010 09:11:53 -0800 (PST) Received: by 10.213.105.79 with HTTP; Sun, 28 Nov 2010 09:11:53 -0800 (PST) In-Reply-To: References: Date: Sun, 28 Nov 2010 12:11:53 -0500 Message-ID: Subject: Re: Taking down a node in a 3-node cluster, RF=2 From: Jake Luciani To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=0015174bdc9c54bf260496200df3 --0015174bdc9c54bf260496200df3 Content-Type: text/plain; charset=ISO-8859-1 If you read/write data with quorum then you can safely take a node down in this scenario. Subsequent writes will use hinted handoff to be passed to the node when it comes back up. More info is here: http://wiki.apache.org/cassandra/HintedHandoff Does that answer your question? -Jake On Sun, Nov 28, 2010 at 9:42 AM, Ran Tavory wrote: > to me it makes sense that if hinted handoff is off then cassandra cannot > satisfy 2 out of every 3rd writes writes when one of the nodes is down since > this node is the designated node of 2/3 writes. > But I don't remember reading this somewhere. Does hinted handoff affect > David's situation? > (David, did you disable HH in your storage-config? > false) > > > On Sun, Nov 28, 2010 at 4:32 PM, David Boxenhorn wrote: > >> For the vast majority of my data usage eventual consistency is fine (i.e. >> CL=ONE) but I have a small amount of critical data for which I read and >> write using CL=QUORUM. >> >> If I have a cluster with 3 nodes and RF=2, and CL=QUORUM does that mean >> that a value can be read from or written to any 2 nodes, or does it have to >> be the particular 2 nodes that store the data? If it is the particular 2 >> nodes that store the data, that means that I can't even take down one node, >> since it will be the mandatory 2nd node for 1/3 of my data... >> > > > > -- > /Ran > > --0015174bdc9c54bf260496200df3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you read/write data with quorum then you can safely take a node down in = this scenario. =A0Subsequent writes will use hinted handoff to be passed to= the node when it comes back up.=A0

More info is here:= =A0http://wiki.a= pache.org/cassandra/HintedHandoff

Does that answer your question?

-Jake


On Sun, Nov= 28, 2010 at 9:42 AM, Ran Tavory <rantav@gmail.com> wrote:
to me it makes sense that = if hinted handoff is off then cassandra cannot satisfy 2 out of every 3rd w= rites writes when one of the nodes is down since this node is the designate= d node of 2/3 writes.=A0
But I don't remember reading this somewhere. Does hinted handoff affect= David's situation?
(David, did you disable HH in your storage-config? <HintedHandoffEn= abled>false</HintedHandoffEnabled>)


On Sun, Nov 28, 2010 at 4:32 PM, David Boxenhorn <da= vid@lookin2.com> wrote:
For the vast majority of my= data usage eventual consistency is fine (i.e. CL=3DONE) but I have a small= amount of critical data for which I read and write using CL=3DQUORUM.

If I have a cluster with 3 nodes and RF=3D2, and CL=3DQUORUM does that = mean that a value can be read from or written to any 2 nodes,=20 or does it have to be the particular 2 nodes that store the data? If it=20 is the particular 2 nodes that store the data, that means that I can't = even take=20 down one node, since it will be the mandatory 2nd node for 1/3 of my=20 data...



--
= /Ran


--0015174bdc9c54bf260496200df3--