Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of sylvain@datastax.com
 designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAPjXCuyXRdG6RkYdWbS0y3PWBcUL_e5qvgBCSLrPf5bqzruLpQ@mail.gmail.com>
References: 
 <CAPjXCuyXRdG6RkYdWbS0y3PWBcUL_e5qvgBCSLrPf5bqzruLpQ@mail.gmail.com>
Date: Fri, 30 Nov 2012 13:19:42 +0100
Message-ID: 
 <CAKkz8Q3jNaSEMudfMYy+whoCRj8LW=xT97AFrgfiUQADgZpAuQ@mail.gmail.com>
Subject: Re: failing reconcilliation during counter increment?
From: Sylvain Lebresne <sylvain@datastax.com>
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Content-Type: multipart/alternative; boundary=20cf307c9e741a53a704cfb56ad0

--20cf307c9e741a53a704cfb56ad0
Content-Type: text/plain; charset=ISO-8859-1

>
> To my understanding client will not be notified because this read step is
> asynchronously.


Yes, though for the record it's actually synchronous if you use anything
else than CL.ONE.


> Also the other replica cannot be updated properly (replicate-on-write
> stage is backing up).
> Question is:
> - Will the counter value eventually become correct?
>

Yes, provided you either have read repair enabled or run repair at some
point. Meaning that if the read gets dropped, there is no hinted hand-off
involved so read repair and repair are the only things that will make
things eventually consistent (but they will).


> - Read repair is turned off for the moment, but would this (not
> reconciliated) memtable  value be merged correctly if read repair would be
> enabled?
>

Yes


> - What with the final value after running nodetool repairs or compaction
> process...
>

It'll be fine.

--
Sylvain

--20cf307c9e741a53a704cfb56ad0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">To my understanding client will not be notified because this read=
 step is asynchronously. </blockquote>
<div><br></div><div>Yes, though for the record it&#39;s actually synchronou=
s if you use anything else than CL.ONE.</div><div>=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
Also the other replica cannot be updated properly (replicate-on-write stage=
 is backing up).<br>Question is: <br>- Will the counter value eventually be=
come correct?<br></blockquote><div><br></div><div>Yes, provided you either =
have read repair enabled or run repair at some point. Meaning that if the r=
ead gets dropped, there is no hinted hand-off involved so read repair and r=
epair are the only things that will make things eventually consistent (but =
they will).</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
- Read repair is turned off for the moment, but would this (not reconciliat=
ed) memtable=A0 value be merged correctly if read repair would be enabled?<=
br></blockquote><div><br></div><div>Yes</div><div>=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
- What with the final value after running nodetool repairs or compaction pr=
ocess...<br></blockquote><div><br></div><div>It&#39;ll be fine.=A0</div><di=
v><br></div><div>--</div><div>Sylvain</div></div></div>

--20cf307c9e741a53a704cfb56ad0--