Return-Path: Delivered-To: apmail-incubator-cassandra-dev-archive@minotaur.apache.org Received: (qmail 85093 invoked from network); 9 Feb 2010 16:21:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 9 Feb 2010 16:21:59 -0000 Received: (qmail 74938 invoked by uid 500); 9 Feb 2010 16:21:58 -0000 Delivered-To: apmail-incubator-cassandra-dev-archive@incubator.apache.org Received: (qmail 74917 invoked by uid 500); 9 Feb 2010 16:21:58 -0000 Mailing-List: contact cassandra-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cassandra-dev@incubator.apache.org Delivered-To: mailing list cassandra-dev@incubator.apache.org Received: (qmail 74907 invoked by uid 99); 9 Feb 2010 16:21:58 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Feb 2010 16:21:58 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jbellis@gmail.com designates 74.125.82.47 as permitted sender) Received: from [74.125.82.47] (HELO mail-ww0-f47.google.com) (74.125.82.47) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Feb 2010 16:21:50 +0000 Received: by wwi14 with SMTP id 14so141695wwi.6 for ; Tue, 09 Feb 2010 08:21:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=sLiXE0SD1VfuWP+hffJ5kygW66xRBIHrq2PqW4eSMHA=; b=TWs7qO8TzWD0rRTxcgXjRtK7GJNOGCH3UTQ8tPKrESeyCllrrLGN9StYGZrgM5E+so 0/48vaEfGfWjh6MPhrbTwY22B2addJjSuXCy7euiefesbNNg4r4+Hn3qFEkE88WBpNMH i2tlO+uhrdPxJSKMwihuhrTQsDI42USGp/G+c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=syV2XnBwoxta2RHry8gwuOvFNWcj740b5ecDo1VKnwncScAZ0ceEoNyas7p6bP5n1t DXegUBxlYvzIOm1IOw/vf/KH1Lf3sa5lKCnsYdikTDgS43Xgi3jpBsyd71nrVOIr2w/U ve1XcA+5tEFFT+GBcopJx3TcsxHCBqaVQc5a4= MIME-Version: 1.0 Received: by 10.216.87.12 with SMTP id x12mr2520468wee.48.1265732490536; Tue, 09 Feb 2010 08:21:30 -0800 (PST) In-Reply-To: References: <1265701447.512616412@192.168.2.230> From: Jonathan Ellis Date: Tue, 9 Feb 2010 10:21:10 -0600 Message-ID: Subject: Re: loadbalance and different strategies To: cassandra-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org On Tue, Feb 9, 2010 at 3:13 AM, Jaakko wrote: > What they probably should do, is to just > consider nodes in the DC they are booting to, and try to balance load > evenly in that DC. I'm not sure what problem that would solve. It seems to me there are two goals: 1. don't transfer data across data centers 2. improve ring balance when you add nodes (1) should always be the case no matter where on the ring the node is since there will be at least one replica of each range in each DC. (2) is where we get into trouble here no matter which DC we add to. (a) if we add to G's DC, X will get all the replicas G has, remaining unbalanced (b) if we add to the other DC, G will still be hit from all the replicas from the other DC So ISTM that the only real solution is to do what we say in the Operations page, and make sure that nodes on the ring alternate DCs. I don't think only considering nodes in the same DC helps with that. -Jonathan