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 E12C5104A2 for ; Fri, 12 Jul 2013 15:35:22 +0000 (UTC) Received: (qmail 35818 invoked by uid 500); 12 Jul 2013 15:35:20 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 35780 invoked by uid 500); 12 Jul 2013 15:35:19 -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 35772 invoked by uid 99); 12 Jul 2013 15:35:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Jul 2013 15:35:18 +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 andrew.bialecki@gmail.com designates 209.85.217.170 as permitted sender) Received: from [209.85.217.170] (HELO mail-lb0-f170.google.com) (209.85.217.170) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Jul 2013 15:35:13 +0000 Received: by mail-lb0-f170.google.com with SMTP id t13so7682987lbd.29 for ; Fri, 12 Jul 2013 08:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z3fIZfoNlYZNz47HsSkoSirn9X2LQSefm2M4JUi83zU=; b=tpe8/TYiwbWmIyhZvGtA/ClRXGNToF9+aza2kUVhI6Xj0dMjT1xkpULzYqCUgFO4F9 d8lDNCsCM0t9dZ/59mWlCUevdMZt5ivoLN8A/r/66/3i8BZxHPicGRyjLsKmDrWiWdj0 oFPnnVCebF07yGBVKqpS7mr1QLkLj7mZFVppjhSJfJU5fP3KD084HRlRL38Ji2zsMqVB 82AL9vyA+iLHAVJ/rUp9P8zIUwBGh7hlz792iG4DReDy+N/OnwhbSPD9anDtcfIivg2Z ZJw+wfz1GHmnaBpsNkT0VUVZ79pe7pOhVupZ3fyUzMIowMyuOBef9S18AhNyoUXnnm8L 9xJw== MIME-Version: 1.0 X-Received: by 10.152.170.197 with SMTP id ao5mr20077833lac.35.1373643292583; Fri, 12 Jul 2013 08:34:52 -0700 (PDT) Received: by 10.112.173.196 with HTTP; Fri, 12 Jul 2013 08:34:52 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Jul 2013 11:34:52 -0400 Message-ID: Subject: Re: node tool ring displays 33.33% owns on 3 node cluster with replication From: Andrew Bialecki To: user@cassandra.apache.org Cc: Francois Richard Content-Type: multipart/alternative; boundary=089e0117746780ae8f04e1524076 X-Virus-Checked: Checked by ClamAV on apache.org --089e0117746780ae8f04e1524076 Content-Type: text/plain; charset=ISO-8859-1 Not sure if it's the best/intended behavior, but you should see it go back to 100% if you run: nodetool -h 127.0.0.1 -p 8080 ring . I think the rationale for showing 33% is that different keyspaces might have different RFs, so it's unclear what to show for ownership. However, if you include the keyspace as part of your query, you'll get it weighted by the RF of that keyspace. I believe the same logic applies for nodetool status. Andrew On Thu, Jul 11, 2013 at 12:58 PM, Jason Tyler wrote: > Thanks Rob! I was able to confirm with getendpoints. > > Cheers, > > ~Jason > > From: Robert Coli > Reply-To: "user@cassandra.apache.org" > Date: Wednesday, July 10, 2013 4:09 PM > To: "user@cassandra.apache.org" > Cc: Francois Richard > Subject: Re: node tool ring displays 33.33% owns on 3 node cluster with > replication > > On Wed, Jul 10, 2013 at 4:04 PM, Jason Tyler wrote: > >> Is this simply a display issue, or have I lost replication? >> > > Almost certainly just a display issue. Do "nodetool -h localhost > getendpoints 0", which will tell you the > endpoints for the non-transformed key "0." It should give you 3 endpoints. > You could also do this test with a known existing key and then go to those > nodes and verify that they have that data on disk via sstable2json. > > (FWIW, it is an odd display issue/bug if it is one. Because it has > reverted to pre-1.1 behavior...) > > =Rob > --089e0117746780ae8f04e1524076 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Not sure if it's the best/intended behavior, but you s= hould see it go back to 100% if you run: nodetool -h 127.0.0.1 -p 8080 ring= <keyspace>.

I think the rationale for showing 33%= is that different keyspaces might have different RFs, so it's unclear = what to show for ownership. However, if you include the keyspace as part of= your query, you'll get it weighted by the RF of that keyspace. I belie= ve the same logic applies for nodetool status.

Andrew

=
On Thu, Jul 11, 2013 at 12:58 PM, Jason Tyle= r <jatyler@yahoo-inc.com> wrote:
Thanks Rob! =A0I was able to confirm with getendpoints.

Cheers,

~Jason


On Wed, Jul 10, 2013 at 4:04 PM, Jason Tyler <jatyler= @yahoo-inc.com> wrote:
Is this simply a display issue, or have I lost replication?

Almost certainly just a display issue. Do "nodetool -h localhost = getendpoints <keyspace> <columnfamily> 0", which will tell= you the endpoints for the non-transformed key "0." It should giv= e you 3 endpoints. You could also do this test with a known existing key and then go to those nodes and verify that they have that dat= a on disk via sstable2json.=A0

(FWIW, it is an odd display issue/bug if it is one. Because it has rev= erted to pre-1.1 behavior...)

=3DRob

--089e0117746780ae8f04e1524076--