From user-return-34266-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Thu May 23 22:00:28 2013 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 13699D2C4 for ; Thu, 23 May 2013 22:00:28 +0000 (UTC) Received: (qmail 8903 invoked by uid 500); 23 May 2013 22:00:25 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 8878 invoked by uid 500); 23 May 2013 22:00:25 -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 8870 invoked by uid 99); 23 May 2013 22:00:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 May 2013 22:00:25 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,TO_NO_BRKTS_PCNT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a79.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 May 2013 22:00:20 +0000 Received: from homiemail-a79.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a79.g.dreamhost.com (Postfix) with ESMTP id 8C30E7D406F for ; Thu, 23 May 2013 14:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thelastpickle.com; h=from :content-type:message-id:mime-version:subject:date:references:to :in-reply-to; s=thelastpickle.com; bh=gThvsgPd+Qs4Z7kWxPzK9PgqwS M=; b=illILO+I+CPeGp7UDwkoNPrHazHNm/7Q6iPXmDUC2+/Y9pKAEu8PhibFys V8ou4RLSDjIQ63BeeTfm1AQVC90gHEInnagiqCFHkqZwv1NA1kQ3YhMNXzdxgg+G IPvvu4X/06guH6c1kZaG1abgZ+CzkZK/Bk3rrsPhdD8u2vgMs= Received: from [172.16.1.8] (unknown [203.86.207.101]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aaron@thelastpickle.com) by homiemail-a79.g.dreamhost.com (Postfix) with ESMTPSA id DAEF17D4059 for ; Thu, 23 May 2013 14:59:28 -0700 (PDT) From: aaron morton Content-Type: multipart/alternative; boundary="Apple-Mail=_E050CCA1-AF49-4818-93FD-44E9DC7FC514" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Cassandra read reapair Date: Fri, 24 May 2013 09:59:57 +1200 References: <833ED583-13CF-45AE-8545-CCF48AD2CB68@thelastpickle.com> To: user@cassandra.apache.org In-Reply-To: X-Mailer: Apple Mail (2.1503) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_E050CCA1-AF49-4818-93FD-44E9DC7FC514 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 If you are reading and writing at CL QUOURM and getting inconsistent = results that sounds like a bug. If you are mixing the CL levels such = that R + W <=3D N then it's expected behaviour.=20 Can you reproduce the issue outside of your app ?=20 Cheers ----------------- Aaron Morton Freelance Cassandra Consultant New Zealand @aaronmorton http://www.thelastpickle.com On 21/05/2013, at 8:55 PM, Kais Ahmed wrote: > > Checking you do not mean the row key is corrupt and cannot be read.=20= > Yes, i can read it but all read don't return the same result except = for CL ALL >=20 > > By default in 1.X and beyond the default read repair chance is 0.1, = so it's only enabled on 10% of requests.=20 > You are right read repair chance is set to 0.1, but i launched a read = repair which did not solved the problem. Any idea? >=20 > >What CL are you writing at ?=20 > All write are in CL QUORUM >=20 > thank you aaron for your answer.=20 >=20 >=20 > 2013/5/21 aaron morton >> Only some keys of one CF are corrupt.=20 > Checking you do not mean the row key is corrupt and cannot be read.=20 >=20 >> I thought using CF ALL, would correct the problem with READ REPAIR, = but by returning to CL QUORUM, the problem persists. >>=20 >=20 > By default in 1.X and beyond the default read repair chance is 0.1, so = it's only enabled on 10% of requests.=20 >=20 >=20 > In the absence of further writes all reads (at any CL) should return = the same value.=20 >=20 > What CL are you writing at ?=20 >=20 > Cheers >=20 > ----------------- > Aaron Morton > Freelance Cassandra Consultant > New Zealand >=20 > @aaronmorton > http://www.thelastpickle.com >=20 > On 19/05/2013, at 1:28 AM, Kais Ahmed wrote: >=20 >> Hi all, >>=20 >> I encountered a consistency problem one some keys using phpcassa and = Cassandra 1.2.3 since a server crash=20 >>=20 >> Only some keys of one CF are corrupt.=20 >>=20 >> I lauched a nodetool repair that successfully completed but don't = correct the issue. >>=20 >>=20 >>=20 >> When i try to get a corrupt Key with : >>=20 >> CL ONE, the result contains 7 or 8 or 9 columns >>=20 >> CL QUORUM, result contains 8 or 9 columns >>=20 >> CL ALL, the data is consistent and returns always 9 columns >>=20 >>=20 >>=20 >> I thought using CF ALL, would correct the problem with READ REPAIR, = but by returning to CL QUORUM, the problem persists. >>=20 >>=20 >> Thank you for your help >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail=_E050CCA1-AF49-4818-93FD-44E9DC7FC514 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 If = you are reading and writing at CL QUOURM and getting inconsistent = results that sounds like a bug. If you are mixing the CL levels such = that R + W <=3D N then it's expected = behaviour. 


Can you = reproduce the issue outside of your app = ? 

Cheers

http://www.thelastpickle.com

On 21/05/2013, at 8:55 PM, Kais Ahmed <kais@neteck-fr.com> = wrote:

> Checking you do not mean the = row key is corrupt and cannot be read.
Yes, i can read it but = all read don't return the same result except for CL ALL

>
By default in 1.X and beyond the = default read repair chance is 0.1, so it's only enabled on 10% of = requests.
You = are right read repair chance is set to 0.1, but i launched a read = repair which did not solved the problem. Any idea?

>What CL are you writing = at ?
All write are in CL = QUORUM

thank you aaron for your answer.


2013/5/21 aaron morton <aaron@thelastpickle.com>
Only some keys of one CF are = corrupt. 
Checking you do not mean the = row key is corrupt and cannot be read. 

I = thought using CF ALL= , would correct = the problem with READ REPAIR= but by = returning to CL QUOR= UMthe problem persists.

By default in 1.X and beyond the default read repair chance = is 0.1, so it's only enabled on 10% of requests. 


In the absence of further writes all reads (at any CL) = should return the same value. 

What CL are = you writing at = ? 

Cheers

-----------------
Aaron Morton
Freelance = Cassandra Consultant
New = Zealand

@aaronmorton

On 19/05/2013, at 1:28 AM, Kais Ahmed <kais@neteck-fr.com> wrote:

Hi all,

I encountered a = consistency problem one some keys using phpcassa and Cassandra 1.2.3 = since a server crash

Only some keys of one CF are corrupt.

I lauched a = nodetool repair that successfully completed but don't correct the = issue.



When i try to get a corrupt Key with = :

CL ONE, the result contains 7 or 8 or 9 columns

CL = QUORUM, result contains 8 or 9 columns

CL ALL, the data is = consistent and returns always 9 columns


I thought using CF = ALL, would correct the = problem with READ = REPAIR, but by = returning to CL = QUORUM, the problem = persists.


Thank you for = your = help






<= /p>




=



= --Apple-Mail=_E050CCA1-AF49-4818-93FD-44E9DC7FC514--