Received: by 10.52.21.68 with SMTP id t4mr14389553vde.8.1334678494678;
        Tue, 17 Apr 2012 09:01:34 -0700 (PDT)
X-BeenThere: codership-team@googlegroups.com
Received: by 10.52.88.105 with SMTP id bf9ls3100213vdb.8.gmail; Tue, 17 Apr
 2012 09:01:34 -0700 (PDT)
Received: by 10.52.33.4 with SMTP id n4mr6861978vdi.1.1334678494250;
        Tue, 17 Apr 2012 09:01:34 -0700 (PDT)
Received: by 10.52.33.4 with SMTP id n4mr6861977vdi.1.1334678494241;
        Tue, 17 Apr 2012 09:01:34 -0700 (PDT)
Return-Path: <henrik.i...@gmail.com>
Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48])
        by gmr-mx.google.com with ESMTPS id cl2si10083591vdc.3.2012.04.17.09.01.34
        (version=TLSv1/SSLv3 cipher=OTHER);
        Tue, 17 Apr 2012 09:01:34 -0700 (PDT)
Received-SPF: pass (google.com: domain of henrik.i...@gmail.com designates 209.85.212.48 as permitted sender) client-ip=209.85.212.48;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henrik.i...@gmail.com designates 209.85.212.48 as permitted sender) smtp.mail=henrik.i...@gmail.com; dkim=pass header...@gmail.com
Received: by vbjk17 with SMTP id k17so6702794vbj.35
        for <codership-team@googlegroups.com>; Tue, 17 Apr 2012 09:01:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:reply-to:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        bh=/G6Q0dyHEbDRIhh7ciM92+7bToHlfH1k/he4BHtNz+g=;
        b=zxprH8vIBXS7gf2LLR1Vlh2RYKLYjzBKKtD8Io2ICq2b1XKE1ulMtmNHrt6lDZvJwZ
         3uaKSi3NVvyhDIwKRARUOMYz2kAf7F0Bd9Y/o6Jw4glv/LdqmZC7VmNR2/MAs39DaSQ9
         PXwnGibbUb0GGjHLkdCTKfzepeMvaYtl8XZaILE/87V4C9ZGfL5rS4WEi2U2y+UN5OfL
         GL3oE7ReeAJBm3jve2j0CJIlo+zVxuqpVPYoOoeeBLgQ8GqWoD6/AZt13fLleuLvBV87
         zZcEitP96jNjmq6FmHytuKoqlqanHZ8JgmAeMqF2i8A52FZE9V6KfsiftgaK1fvoimMg
         4x/w==
MIME-Version: 1.0
Received: by 10.52.64.173 with SMTP id p13mr7395619vds.51.1334678494048; Tue,
 17 Apr 2012 09:01:34 -0700 (PDT)
Reply-To: henrik.i...@avoinelama.fi
Sender: henrik.i...@gmail.com
Received: by 10.220.181.9 with HTTP; Tue, 17 Apr 2012 09:01:33 -0700 (PDT)
In-Reply-To: <4886238.2099.1334677838552.JavaMail.geo-discussion-forums@ynaz34>
References: <13101417.830.1334612598704.JavaMail.geo-discussion-forums@ynhh34>
	<CAKHykevKp_a0jsTi5V5=oLekE8eXYhouprxRD3nVTxqA4a2...@mail.gmail.com>
	<4886238.2099.1334677838552.JavaMail.geo-discussion-forums@ynaz34>
Date: Tue, 17 Apr 2012 19:01:33 +0300
Message-ID: <CAKHykeuZ8YVyv-VP75sBcirdxJ7T-k-YwJoHxGyEf+V9ayx...@mail.gmail.com>
Subject: Re: [codership-team] Consistent Reads - Are they possible?
From: Henrik Ingo <henrik.i...@avoinelama.fi>
To: karlito <karl.pick...@gmail.com>
Cc: codership-team@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 17, 2012 at 6:50 PM, karlito <karl.pick...@gmail.com> wrote:
> Yes, I noticed we will have to turn the casual reads setting on. =A0 Does=
 the
> casual read setting turn on extra network overhead on reads, or does it j=
ust
> wait for the local threads to finish? =A0 I thought it was the latter, bu=
t the
> docs aren't clear ("Results in larger read latencies.")

Yes. Basically all SELECTS will wait for their pending slave queue to
be applied before they read. There is no additional network
connectivity to other nodes, just a delay before the read can be
"securely" executed.

Note that if read-causality is important to you (for most applications
I would say that an inconsistency of at most some milliseconds is not
an issue) then another way around this is to direct all writes and
reads to a single node.

> Exactly how long does it take for n3 to notice it has lost the cluster? =
=A0My
> cursory reading would indicate it would time all other nodes out
> after=A0inactive_timeout, which is bad since thats 15 seconds (longer the=
n the
> main cluster times n3 out). =A0Is that incorrect?

Note that you can configure these values to suit your own needs. The
defaults are fairly lax, so making these timeouts tighter is certainly
an option.

henrik
--=20
henrik.i...@avoinelama.fi
+358-40-8211286 skype: henrik.ingo irc: hingo
www.openlife.cc

My LinkedIn profile: http://www.linkedin.com/profile/view?id=3D9522559