Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 88747 invoked from network); 24 Mar 2011 13:47:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 24 Mar 2011 13:47:20 -0000 Received: (qmail 81237 invoked by uid 500); 24 Mar 2011 13:47:18 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 81209 invoked by uid 500); 24 Mar 2011 13:47:18 -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 81201 invoked by uid 99); 24 Mar 2011 13:47:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Mar 2011 13:47:18 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jonathan.colby@gmail.com designates 209.85.214.44 as permitted sender) Received: from [209.85.214.44] (HELO mail-bw0-f44.google.com) (209.85.214.44) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Mar 2011 13:47:09 +0000 Received: by bwz13 with SMTP id 13so58569bwz.31 for ; Thu, 24 Mar 2011 06:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=m8CtmMYh1XRFg72jjrOCBQQIzjbLsmUmC8ykSj6dW1Y=; b=s6ypyPckXcd/Eu+oknsJYgmLpGEeAhJY0WCdEZAziPmR16oS8Qyhq5P4ompl4rp/LX +FKpWcqgf0nqod0typtmZ5/cFRh7MVkyPru5xY595iSFYSs02cO1AHT4PX8Zhqggk/Sl RdqADotGQAkPkYt744hUlen13xw9OTKl8Kr7A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=wwHeKSuMQAYFgDmpP3+R0K4Kn0X6x6UaSPAiULa451bq0tz8iuFSyCenM/r6xbuLKU Cj3P2Se9zf3gg3k3ypEHbeqkD+Nwvy+lrFfJXRKAhhherqmG5eHOJU9nnJ9N8rTYy9c2 Ts4bx01Dz9Wn2aCGkzhpJiJdsTLUHNDypqQBk= Received: by 10.223.31.133 with SMTP id y5mr2574036fac.7.1300974399293; Thu, 24 Mar 2011 06:46:39 -0700 (PDT) Received: from siteop-12.mobile.rz ([194.50.70.51]) by mx.google.com with ESMTPS id l2sm68433fam.29.2011.03.24.06.46.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Mar 2011 06:46:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: Quorum, Hector, and datacenter preference From: Jonathan Colby In-Reply-To: <52BE6DCD-68AC-45D1-B6CD-7F5CA19339B9@gmail.com> Date: Thu, 24 Mar 2011 14:46:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8ABEC3B3-1612-440D-A0D7-88CCF9EAFBC0@gmail.com> References: <52BE6DCD-68AC-45D1-B6CD-7F5CA19339B9@gmail.com> To: user@cassandra.apache.org X-Mailer: Apple Mail (2.1082) X-Virus-Checked: Checked by ClamAV on apache.org Indeed I found the big flaw in my own logic. Even writing to the = "local" cassandra nodes does not guarantee where the replicas will end = up. The decision where to write the first replica is based on the = token ring, which is spread out on all nodes regardless of datacenter. = right ? On Mar 24, 2011, at 2:02 PM, Jonathan Colby wrote: > Hi - >=20 > Our cluster is spread between 2 datacenters. We have a = straight-forward IP assignment so that OldNetworkTopology (rackinferring = snitch) works well. We have cassandra clients written in Hector in = each of those data centers. The Hector clients all have a list of all = cassandra nodes across both data centers. RF=3D3. >=20 > Is there an order as to which data center gets the first write? In = other words, would (or can) the Hector client do its first write to the = cassandra nodes in its own data center? >=20 > It would be ideal it Hector chose the "local" cassandra nodes. That = way, if one data center is unreachable, the Quorum of replicas in = cassandra is still reached (because it was written to the working data = center first). >=20 > Otherwise, if the cassandra writes are really random from the Hector = client point-of-view, a data center outage would result in a read = failure for any data that has 2 replicas in the lost data center. >=20 > Is anyone doing this? Is there a flaw in my logic? >=20 >=20