Return-Path: Delivered-To: apmail-incubator-cassandra-user-archive@minotaur.apache.org Received: (qmail 864 invoked from network); 25 Feb 2010 07:36:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 25 Feb 2010 07:36:00 -0000 Received: (qmail 3559 invoked by uid 500); 25 Feb 2010 07:36:00 -0000 Delivered-To: apmail-incubator-cassandra-user-archive@incubator.apache.org Received: (qmail 3539 invoked by uid 500); 25 Feb 2010 07:36:00 -0000 Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cassandra-user@incubator.apache.org Delivered-To: mailing list cassandra-user@incubator.apache.org Received: (qmail 3531 invoked by uid 99); 25 Feb 2010 07:36:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Feb 2010 07:36:00 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of masoodmortazavi@gmail.com designates 209.85.160.47 as permitted sender) Received: from [209.85.160.47] (HELO mail-pw0-f47.google.com) (209.85.160.47) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Feb 2010 07:35:53 +0000 Received: by pwi5 with SMTP id 5so5202656pwi.6 for ; Wed, 24 Feb 2010 23:35:33 -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 :date:message-id:subject:from:to:content-type; bh=z7/x5WBaOyu14hEsz/nshwa6APDdHItf9HJPltIHJkI=; b=uZlt7IUHG6+hJR6IPohCB8GAtouhDar1U4v//C2LdvrSKGwxl7pGPilNB1msjFda9N EuuH7DkoNF0TG92Tjanby3ooEiINxyHUPASfg6M4T7t8kW5gXp2efAYZ5DBxS6hcz8/l gIDs9eYaAGegZkFVDAzXhqhX+hEZwsm2u6hmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=FlsRRVnFCrQZwJ2lmdi5bJ6/dlMFOi4CzhAZNFX7kWliDdDg5NGrVFHItbvbd+KBGT qxacULKZLc88gAKJ0xi+t3jkbbXSQg+dXZq0UkAkaTn108XyLGW8NhAYh/oUowBC2YrX 11mAQs9JJKQudflVuKAx2HCVBCpQht8kNRbqY= MIME-Version: 1.0 Received: by 10.140.55.11 with SMTP id d11mr384612rva.211.1267083333322; Wed, 24 Feb 2010 23:35:33 -0800 (PST) In-Reply-To: References: Date: Wed, 24 Feb 2010 23:35:33 -0800 Message-ID: Subject: Re: 3 node installation From: Masood Mortazavi To: cassandra-user@incubator.apache.org Content-Type: multipart/alternative; boundary=0016369207c6fbc8fb048067d308 --0016369207c6fbc8fb048067d308 Content-Type: text/plain; charset=ISO-8859-1 Besides what I just said below, I should have also added that in the scenario discussed here: While RackUnawareStrategy is used ... Node B which seems to have a copy of all data at all times, has an IP address whose 3rd octet is different from IP addresses of both node A and C, which have the same third octet. A, B and C are all set as "Seed" in the "seeds" section. Bootstrap is set true for all of them. In storage-conf.xml, the only thing that differs for the three nodes is their own interfaces. As just noted, the Replica factor is 2. That's it. On Wed, Feb 24, 2010 at 11:18 PM, Masood Mortazavi < masoodmortazavi@gmail.com> wrote: > Yes. > Identical with replication factor of 2. > m. > > > On Wed, Feb 24, 2010 at 8:33 PM, Jonathan Ellis wrote: > >> Is the configuration identical on all nodes? Specifically, is >> ReplicationFactor set to 2 on all nodes? >> >> On Wed, Feb 24, 2010 at 10:07 PM, Masood Mortazavi >> wrote: >> > I wonder if anyone can provide an explanation for the following behavior >> > observed in a three-node cluster: >> > >> > 1. In a three-node (A, B and C) installation, I use the cli, connected >> to >> > node A, to set 10 data items. >> > >> > 2. On cli connected to node A, I do get, and can see all 10 data items. >> > >> > 3. I take node C down, I do step 2, and only see some of the 10 data >> items. >> > Some of the data items are unavailable as follows: >> > cassandra> get Keyspace1.Standard1['test6'] >> > Exception null >> > UnavailableException() >> > at >> > org.apache.cassandra.service.Cassandra$get_slice_result.read(Cassandr >> > a.java:3274) >> > at >> > org.apache.cassandra.service.Cassandra$Client.recv_get_slice(Cassandr >> > a.java:296) >> > at >> > org.apache.cassandra.service.Cassandra$Client.get_slice(Cassandra.jav >> > a:270) >> > at >> org.apache.cassandra.cli.CliClient.doSlice(CliClient.java:241) >> > at >> org.apache.cassandra.cli.CliClient.executeGet(CliClient.java:300) >> > at >> > org.apache.cassandra.cli.CliClient.executeCLIStmt(CliClient.java:57) >> > at >> org.apache.cassandra.cli.CliMain.processCLIStmt(CliMain.java:131) >> > at org.apache.cassandra.cli.CliMain.main(CliMain.java:172) >> > >> > 4. Following step 3, with no other changes other than connecting the >> same >> > cli instance to the other remaining node, meaning node B (which is a >> node >> > with largest memory, by the way, although I don't think it matters >> here), I >> > can see all 10 test data items. >> > >> > The replica number is 2. >> > >> > >> > >> > > --0016369207c6fbc8fb048067d308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Besides what I just said below, I should have also added that in the scenar= io discussed here:

While RackUn= awareStrategy is used ...=A0

Node B which seems to have a copy of all data at all times, has an IP a= ddress whose 3rd octet is different from IP addresses of both node A and C,= which have the same third octet.=A0

A, B and C are all set as "= ;Seed" in the "seeds" section.

Bootstrap is set true for all of them.

= In storage-conf.xml, the only thing that differs for the three nodes is the= ir own interfaces.=A0
As just noted, the Replica factor is 2.=A0<= /div>
That's it.=A0

On Wed, Feb= 24, 2010 at 11:18 PM, Masood Mortazavi <masoodmortazavi@gmail.com> wr= ote:
Yes.
Identical with replication factor = of 2.
m.


On Wed, Feb 24, 2010 at 8:33 PM, Jonatha= n Ellis <jbellis@gmail.com> wrote:
Is the configuration identical on all nodes?= =A0Specifically, is
ReplicationFactor set to 2 on all nodes?

On Wed, Feb 24, 2010 at 10:07 PM, Masood Mortazavi
<masoodmo= rtazavi@gmail.com> wrote:
> I wonder if anyone can provide an explanation for the following behavi= or
> observed in a three-node cluster:
>
> 1. In a three-node (A, B and C) installation, I use the cli, connected= to
> node A, to set 10 data items.
>
> 2. On cli connected to node A, I do get, and can see all 10 data items= .
>
> 3. I take node C down, I do step 2, and only see some of the 10 data i= tems.
> Some of the data items are unavailable as follows:
> cassandra> get Keyspace1.Standard1['test6']
> Exception null
> UnavailableException()
> =A0=A0=A0=A0=A0=A0=A0 at
> org.apache.cassandra.service.Cassandra$get_slice_result.read(Cassandr<= br> > a.java:3274)
> =A0=A0=A0=A0=A0=A0=A0 at
> org.apache.cassandra.service.Cassandra$Client.recv_get_slice(Cassandr<= br> > a.java:296)
> =A0=A0=A0=A0=A0=A0=A0 at
> org.apache.cassandra.service.Cassandra$Client.get_slice(Cassandra.jav<= br> > a:270)
> =A0=A0=A0=A0=A0=A0=A0 at org.apache.cassandra.cli.CliClient.doSlice(Cl= iClient.java:241)
> =A0=A0=A0=A0=A0=A0=A0 at org.apache.cassandra.cli.CliClient.executeGet= (CliClient.java:300)
> =A0=A0=A0=A0=A0=A0=A0 at
> org.apache.cassandra.cli.CliClient.executeCLIStmt(CliClient.java:57) > =A0=A0=A0=A0=A0=A0=A0 at org.apache.cassandra.cli.CliMain.processCLISt= mt(CliMain.java:131)
> =A0=A0=A0=A0=A0=A0=A0 at org.apache.cassandra.cli.CliMain.main(CliMain= .java:172)
>
> 4. Following step 3, with no other changes other than connecting the s= ame
> cli instance to the other remaining node, meaning node B (which is a n= ode
> with largest memory, by the way, although I don't think it matters= here), I
> can see all 10 test data items.
>
> The replica number is 2.
>
>
>


--0016369207c6fbc8fb048067d308--