Return-Path: 
 <dev-return-4865-apmail-cassandra-dev-archive=cassandra.apache.org@cassandra.apache.org>
X-Original-To: apmail-cassandra-dev-archive@www.apache.org
Delivered-To: apmail-cassandra-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 5D9249556
	for <apmail-cassandra-dev-archive@www.apache.org>;
 Thu, 10 Nov 2011 22:10:01 +0000 (UTC)
Received: (qmail 87552 invoked by uid 500); 10 Nov 2011 22:09:58 -0000
Delivered-To: apmail-cassandra-dev-archive@cassandra.apache.org
Received: (qmail 87521 invoked by uid 500); 10 Nov 2011 22:09:58 -0000
Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@cassandra.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@cassandra.apache.org>
List-Post: <mailto:dev@cassandra.apache.org>
List-Id: <dev.cassandra.apache.org>
Reply-To: dev@cassandra.apache.org
Delivered-To: mailing list dev@cassandra.apache.org
Received: (qmail 87505 invoked by uid 99); 10 Nov 2011 22:09:58 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Nov 2011 22:09:58 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of subrahmanyaharve@gmail.com
 designates 209.85.216.44 as permitted sender)
Received: from [209.85.216.44] (HELO mail-qw0-f44.google.com) (209.85.216.44)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Nov 2011 22:09:53 +0000
Received: by qadb40 with SMTP id b40so1633707qad.10
        for <multiple recipients>; Thu, 10 Nov 2011 14:09:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        bh=5Ho5OsUZIkUASKjV1AEmXeI261tv/Vhgs3j6jgG2s3A=;
        b=dzzPBsPUEUDthe62trXhbPjueyvXxEG669HAq9ZySiyDThwbppwwvtbYVxGE+Z2dtv
         wk/rae6f5GQF513xg8aUcZUxf7DRDBVmnw3lszjoiJq2PA15aEnkZcndZfbx1P8GYAt4
         koglOWVMmDVACSSpREajddjUR7eqsWVXdgp2U=
MIME-Version: 1.0
Received: by 10.229.240.139 with SMTP id la11mr1500013qcb.27.1320962972544;
 Thu, 10 Nov 2011 14:09:32 -0800 (PST)
Received: by 10.229.11.36 with HTTP; Thu, 10 Nov 2011 14:09:32 -0800 (PST)
In-Reply-To: <4EBC4293.8090705@morningstar.com>
References: 
 <CAKMSimHwcgQhF5hMXS3H4n7La15wtVAYM8vjUXMhNcixCaRaCQ@mail.gmail.com>
	<4EBC4293.8090705@morningstar.com>
Date: Thu, 10 Nov 2011 14:09:32 -0800
Message-ID: 
 <CAKMSimEP6+dvK0aKUm2UVvr7XPPYqFGQhLJ=zEsFxUoxkwNHqQ@mail.gmail.com>
Subject: Re: Data retrieval inconsistent
From: Subrahmanya Harve <subrahmanyaharve@gmail.com>
To: dev@cassandra.apache.org
Cc: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=0016363b83eebd6f9604b168a83c

--0016363b83eebd6f9604b168a83c
Content-Type: text/plain; charset=ISO-8859-1

Thanks Ed and Jeremiah for that useful info.
"I am pretty sure the way you have K1 configured it will be placed across
both DC's as if you had large ring.  If you want it only in DC1 you need to
say DC1:1, DC2:0."
Infact i do want K1 to be available across both DCs as if i had a large
ring. I just do not want them to replicate over across DCs. Also i did try
doing it like you said DC1:1, DC2:0 but wont that mean that, all my data
goes into DC1 irrespective of whether the data is getting into the nodes of
DC1 or DC2, thereby creating a "hot DC"? Since the volume of data for this
case is huge, that might create a load imbalance on DC1? (Am i missing
something?)


On Thu, Nov 10, 2011 at 1:30 PM, Jeremiah Jordan <
jeremiah.jordan@morningstar.com> wrote:

> I am pretty sure the way you have K1 configured it will be placed across
> both DC's as if you had large ring.  If you want it only in DC1 you need to
> say DC1:1, DC2:0.
> If you are writing and reading at ONE you are not guaranteed to get the
> data if RF > 1.  If RF = 2, and you write with ONE, you data could be
> written to server 1, and then read from server 2 before it gets over there.
>
> The differing on server times will only really matter for TTL's.  Most
> everything else works off comparing user supplied times.
>
> -Jeremiah
>
>
> On 11/10/2011 02:27 PM, Subrahmanya Harve wrote:
>
>>
>> I am facing an issue in 0.8.7 cluster -
>>
>> - I have two clusters in two DCs (rather one cross dc cluster) and two
>> keyspaces. But i have only configured one keyspace to replicate data to the
>> other DC and the other keyspace to not replicate over to the other DC.
>> Basically this is the way i ran the keyspace creation  -
>>    create keyspace K1 with placement_strategy='org.**
>> apache.cassandra.locator.**SimpleStrategy' and strategy_options =
>> [{replication_factor:1}];
>>    create keyspace K2 with placement_strategy='org.**
>> apache.cassandra.locator.**NetworkTopologyStrategy' and strategy_options
>> = [{DC1:2, DC2:2}];
>>
>> I had to do this because i expect that K1 will get a large volume of data
>> and i do not want this wired over to the other DC.
>>
>> I am writing the data at CL=ONE and reading the data at CL=ONE. I am
>> seeing an issue where sometimes i get the data and other times i do not see
>> the data. Does anyone know what could be going on here?
>>
>> A second larger question is  - i am migrating from 0.7.4 to 0.8.7 , i can
>> see that there are large changes in the yaml file, but a specific question
>> i had was - how do i configure disk_access_mode like it used to be in 0.7.4?
>>
>> One observation i have made is that some nodes of the cross dc cluster
>> are at different system times. This is something to fix but could this be
>> why data is sometimes retrieved and other times not? Or is there some other
>> thing to it?
>>
>> Would appreciate a quick response.
>>
>

--0016363b83eebd6f9604b168a83c--