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 9B461DA7E for ; Thu, 30 Aug 2012 17:19:10 +0000 (UTC) Received: (qmail 18471 invoked by uid 500); 30 Aug 2012 17:19:08 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 18442 invoked by uid 500); 30 Aug 2012 17:19:08 -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 18422 invoked by uid 99); 30 Aug 2012 17:19:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Aug 2012 17:19:07 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FSL_RCVD_USER,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of casey@deccio.net designates 209.85.212.44 as permitted sender) Received: from [209.85.212.44] (HELO mail-vb0-f44.google.com) (209.85.212.44) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Aug 2012 17:19:03 +0000 Received: by vbbez10 with SMTP id ez10so2514128vbb.31 for ; Thu, 30 Aug 2012 10:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=yDvQysFZx8NDjgDHWhyBqYdg28wj10b+D4xy9ZXZjLA=; b=UK68q76eJOx0PC+Sgi2zghTQDq1mb7v4leddlbdqS136SIFFm5pw89FSbIlywCUgwN UfPs0WWWTnnU29FOcWP34+EXsKJcZQvkZhfJZSphv37j30WqkvACh1+rw3MSVbi9fYf9 y/wsJAZpam7jcEYYwV34gqJXBs8xVXcsX5f1Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=yDvQysFZx8NDjgDHWhyBqYdg28wj10b+D4xy9ZXZjLA=; b=JgxM93dUOzFTIN9N7lvSyYaQDdoYHlevvbmuu9HgwRxF1/bnrJcbgUObkNstXBc4jE iuEmRQZ1qWgZzvhmjxXJS00YchGm6aPpsIsY9UKxYBlmVTnpsHUJ0xko+N/4BWwOSwWl 9FnJ3RhY2aj0eo3CmaXTc1bAXvt65xxhtI2Z9XeqIcUYJ9MKCvwTMNYTLPyUZ8IPBnSO bgoDB3nnomCAfD37GsQgvbj90MJLglbSohqaMTolOOEhuZjO0bdMbrgOSdopPrGJSoAF T0fr86ILLmmCro2aAl8NkWXdOtRh14LXrCJArQsERlSMCJ+5Mi3PRQzqS8desUxhyTIW y8hA== MIME-Version: 1.0 Received: by 10.52.27.38 with SMTP id q6mr3069750vdg.81.1346347121953; Thu, 30 Aug 2012 10:18:41 -0700 (PDT) Received: by 10.58.32.234 with HTTP; Thu, 30 Aug 2012 10:18:41 -0700 (PDT) Date: Thu, 30 Aug 2012 10:18:41 -0700 Message-ID: Subject: adding node to cluster From: Casey Deccio To: user Content-Type: multipart/alternative; boundary=20cf307f3438f2cd4f04c87eddbe X-Gm-Message-State: ALoCoQmmx3COnAUSR0/ZUPAt8yzGSmuD5r5ZQlFnx2jmPmDdLjkx4VBb2Ogwy+x4L0i42wnF3EYN X-Virus-Checked: Checked by ClamAV on apache.org --20cf307f3438f2cd4f04c87eddbe Content-Type: text/plain; charset=ISO-8859-1 All, I'm adding a new node to an existing cluster that uses ByteOrderedPartitioner. The documentation says that if I don't configure a token, then one will be automatically generated to take load from an existing node. What I'm finding is that when I add a new node, (super) column lookups begin failing (not sure if it was the row lookup failing or the supercolumn lookup failing), and I'm not sure why. I assumed that while the existing node is transitioning data to the new node the affected rows and (super) columns would still be found in the right place. Any idea why these lookups might be failing? When I decommissioned the the new node, the lookups began working again. Any help is appreciated. Regards, Casey --20cf307f3438f2cd4f04c87eddbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,

I'm adding a new node to an existing cluster that uses Byte= OrderedPartitioner.=A0 The documentation says that if I don't configure= a token, then one will be automatically generated to take load from an exi= sting node.=A0 What I'm finding is that when I add a new node, (super) = column lookups begin failing (not sure if it was the row lookup failing or = the supercolumn lookup failing), and I'm not sure why.=A0 I assumed tha= t while the existing node is transitioning data to the new node the affecte= d rows and (super) columns would still be found in the right place.=A0 Any = idea why these lookups might be failing?=A0 When I decommissioned the the n= ew node, the lookups began working again.=A0 Any help is appreciated.

Regards,
Casey
--20cf307f3438f2cd4f04c87eddbe--