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 48BFC1166A for ; Wed, 18 Jun 2014 06:40:54 +0000 (UTC) Received: (qmail 60716 invoked by uid 500); 18 Jun 2014 06:40:50 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 60675 invoked by uid 500); 18 Jun 2014 06:40:50 -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 60664 invoked by uid 99); 18 Jun 2014 06:40:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Jun 2014 06:40:50 +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 (nike.apache.org: domain of ben@instaclustr.com designates 209.85.160.53 as permitted sender) Received: from [209.85.160.53] (HELO mail-pb0-f53.google.com) (209.85.160.53) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Jun 2014 06:40:47 +0000 Received: by mail-pb0-f53.google.com with SMTP id uo5so404675pbc.40 for ; Tue, 17 Jun 2014 23:40:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=pV6Wm8ucT6Z3cTC/qwiU3OFLKSGEaag0tRbwm7fQH1Q=; b=W5dYOIG+2poEfhMYCHKFiWN62bKPulDMdqWQDGVpTbGhFR/pXI+F7rYvYm3fbzfmG8 opN15XDogGR9GaEHfQHekiv0UAbNF9A0abr3x7PZyUSHVg9bKmdQEqAyZoU7bLjoZvZL +3oHsojfysct1RxejUlPaGbWYI38E4oHTNmfw3G/rhxE+uY9ClaEMvwzWGJTWy0Y9AGz sHccJ8kTv2lYLXBDv2tWJnP/dBu6zvhae0e8vfQqI8UvixHm64XSqwO+zhJtpfwN6+zw KbaBVimmOWU5zPoavgzxWwWs33UlJEyKfg7dNyWo1ZAvbLuRKc4YJp0Tcemix/FN3+dq bCrA== X-Gm-Message-State: ALoCoQlMBx1E9m8aeCvDIcl4CkM4K0KV+hyZMT1dlIeKISrBwAME64OGKz1ko0HZodxT3nnWdLaU X-Received: by 10.66.189.169 with SMTP id gj9mr37684508pac.149.1403073622656; Tue, 17 Jun 2014 23:40:22 -0700 (PDT) Received: from [192.168.1.25] (124-171-96-95.dyn.iinet.net.au. [124.171.96.95]) by mx.google.com with ESMTPSA id zn9sm5485378pac.31.2014.06.17.23.40.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 23:40:22 -0700 (PDT) From: Ben Bromhead Content-Type: multipart/alternative; boundary="Apple-Mail=_6A3CECDC-4BE4-4EC2-8DE6-A02EB43EFA3A" Message-Id: <2A3A814F-F4EF-4370-ABB7-AEA7201DBACE@instaclustr.com> Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: Minimum Cluster size to accommodate a single node failure Date: Wed, 18 Jun 2014 16:40:18 +1000 References: To: user@cassandra.apache.org In-Reply-To: X-Mailer: Apple Mail (2.1822) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_6A3CECDC-4BE4-4EC2-8DE6-A02EB43EFA3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes your thinking is correct. This article from TLP sums it all up beautifully = http://thelastpickle.com/blog/2011/06/13/Down-For-Me.html=20 Ben Bromhead Instaclustr | www.instaclustr.com | @instaclustr | +61 415 936 359 On 18 Jun 2014, at 4:18 pm, Prabath Abeysekara = wrote: > Sorry, the title of this thread has to be "Minimum cluster size to = survive a single node failure". >=20 >=20 > On Wed, Jun 18, 2014 at 11:38 AM, Prabath Abeysekara = wrote: > Hi Everyone, >=20 > First of all, apologies if the $subject was discussed previously in = this list before. I've already gone through quite a few email trails on = this but still couldn't find a convincing answer which really made me = raise this question again here in this list. >=20 > If my understanding is correct, a 3 node Cassandra cluster would = survive a single node failure while the Replication Factor is set to 3 = with consistency levels are assigned QUORUM for read/write operations. = For example, let's consider the following configuration. >=20 > * Number of nodes in the cluster : 3 > * Replication Factor : 3 > * Read/Write consistencies : QUORUM (this evaluates to 2 when RF is = set to 3) >=20 > Here's how I expect it to work. >=20 > Whenever a read operation takes place, the Cassandra cluster = coordinator node that receives the read request would try to read from = at least two replicas before responding to the client. With Read = consistency being 2 (+ all raws being available in all three nodes), we = should be able to survive a single node failure in this particular = instance for read operations. Similarly, for write requests, even in the = middle of a single node failure, the writes should be allowed as the = Write consistency is set to 2?=20 >=20 > Can someone please confirm whether what's mentioned above is correct?=20= > (Please note that I'm trying to figure out the minimum node numbers = and I indeed am aware of the fact that there are other factors also to = be considered in order to come up with the most optimal numbers for a = given cluster requirement). >=20 >=20 > Cheers, > Prabath > --=20 > Prabath >=20 >=20 >=20 > --=20 > Prabath --Apple-Mail=_6A3CECDC-4BE4-4EC2-8DE6-A02EB43EFA3A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Yes your thinking is correct.

This article from TLP sums it all up beautifully http://thelastpickle.com/blog/2011/06/13/Down-For-Me.html 

Ben Bromhead
Instaclustr | www.instaclustr.com | @instaclustr | +61 415 936 359

On 18 Jun 2014, at 4:18 pm, Prabath Abeysekara <prabathabeysekara@gmail.com> wrote:

Sorry, the title of this thread has to be "Minimum cluster size to survive a single node failure".


On Wed, Jun 18, 2014 at 11:38 AM, Prabath Abeysekara <prabathabeysekara@gmail.com> wrote:
Hi Everyone,

First of all, apologies if the $subject was discussed previously in this list before. I've already gone through quite a few email trails on this but still couldn't find a convincing answer which really made me raise this question again here in this list.

If my understanding is correct, a 3 node Cassandra cluster would survive a single node failure while the Replication Factor is set to 3 with consistency levels are assigned QUORUM for read/write operations. For example, let's consider the following configuration.

* Number of nodes in the cluster : 3
* Replication Factor : 3
* Read/Write consistencies : QUORUM (this evaluates to 2 when RF is set to 3)

Here's how I expect it to work.

Whenever a read operation takes place, the Cassandra cluster coordinator node that receives the read request would try to read from at least two replicas before responding to the client. With Read consistency being 2 (+ all raws being available in all three nodes), we should be able to survive a single node failure in this particular instance for read operations. Similarly, for write requests, even in the middle of a single node failure, the writes should be allowed as the Write consistency is set to 2? 

Can someone please confirm whether what's mentioned above is correct? 
(Please note that I'm trying to figure out the minimum node numbers and I indeed am aware of the fact that there are other factors also to be considered in order to come up with the most optimal numbers for a given cluster requirement).


Cheers,
Prabath
--
Prabath



--
Prabath

--Apple-Mail=_6A3CECDC-4BE4-4EC2-8DE6-A02EB43EFA3A--