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 C95A6D2CB for ; Tue, 21 May 2013 08:56:11 +0000 (UTC) Received: (qmail 25322 invoked by uid 500); 21 May 2013 08:56:09 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 25263 invoked by uid 500); 21 May 2013 08:56:09 -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 25232 invoked by uid 99); 21 May 2013 08:56:08 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 May 2013 08:56:08 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,TO_NO_BRKTS_PCNT X-Spam-Check-By: apache.org Received-SPF: unknown (nike.apache.org: error in processing during lookup of kais@neteck-fr.com) Received: from [209.85.214.180] (HELO mail-ob0-f180.google.com) (209.85.214.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 May 2013 08:56:02 +0000 Received: by mail-ob0-f180.google.com with SMTP id xk17so406918obc.39 for ; Tue, 21 May 2013 01:55:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=adbl0+1veWjVW0unmchjPHoku4GNHJ38LN2zhHLYuks=; b=B8sY9/BxNxYKHPVi56BEpThuzgWn7bkqnwfgsVvYmKVGGjN765TnuLFJGbybVksEAX JE9GruNgIhNDHycGPVo+pOaxwb4C6jGOgbEZJrwnVFNUyrr8t3WRkqf/iepHfY7HqJIj hskzUY2ZWK+tt+ss5iOdnlKeiJ5t9h1IjO2gklE8kjnPEQAIBnYVuMQOyqpW2P2s3zsL sFjIWI+7Hel5OWAaiPJaS65V2GxsfPpBElWZDK+umW2NLwl+XYTLXqww2jTx42ewrwST bsj0NFyMBmkksfRajGaaupg4zQ9TdkNLbrzdizo2Y//Au80uGaErpYGHV5NERmq8KExt Itag== MIME-Version: 1.0 X-Received: by 10.60.65.5 with SMTP id t5mr748814oes.139.1369126539794; Tue, 21 May 2013 01:55:39 -0700 (PDT) Received: by 10.182.98.233 with HTTP; Tue, 21 May 2013 01:55:39 -0700 (PDT) In-Reply-To: <833ED583-13CF-45AE-8545-CCF48AD2CB68@thelastpickle.com> References: <833ED583-13CF-45AE-8545-CCF48AD2CB68@thelastpickle.com> Date: Tue, 21 May 2013 10:55:39 +0200 Message-ID: Subject: Re: Cassandra read reapair From: Kais Ahmed To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001a11c1d6a80ef64704dd369d95 X-Gm-Message-State: ALoCoQkxLdpRPVYhjg2lC/0dd1f7C68r3Ov/3X8bATDCwIg+Ok3vvVJcvqtqH7YdgNoV1sT2SU9Q X-Virus-Checked: Checked by ClamAV on apache.org --001a11c1d6a80ef64704dd369d95 Content-Type: text/plain; charset=ISO-8859-1 > 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 > 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 QUORUM, the 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 > http://www.thelastpickle.com > > On 19/05/2013, at 1:28 AM, Kais Ahmed 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 > > > > > > > > > > > --001a11c1d6a80ef64704dd369d95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Checking you do not mean the row key is corrupt = and cannot be read.
Yes, i can read it but all read don't ret= urn the same result except for CL = ALL

> By default in 1.X and beyond the de= fault read repair chance is 0.1, so it's only enabled on 10% of request= s.
You a<= span class=3D"">re right <= span>read repair chance is set to 0.1, but i launched a read repair which d= id not solved the problem. Any idea?

>What CL are you writi= ng at ?
All write are in CL QUORUM
=
thank you aaron for your answer.


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

I thought=A0using=A0CF=A0ALL,=A0would=A0correct the=A0pro= blem=A0with=A0READ<= /span>=A0REPAIR,=A0but=A0by returnin= g=A0to=A0CL=A0QUORUM,=A0the problem=A0persists.

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

<= div>
In the absence of further writes all reads (at any CL) shoul= d return the same value.=A0

What CL are you writin= g at ?=A0

Cheers

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


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

I encountere= d a consistency problem one some keys using phpcassa and Cassandra 1.2.3 si= nce a server crash

Only some keys of one CF are corrupt.

I lauched a no= detool repair that successfully completed but don't correct the issue.<= br>



When i try to get a corrupt Key with :

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

CL QUORUM, re= sult contains 8 or 9 columns

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


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


Thank you for your h= elp











--001a11c1d6a80ef64704dd369d95--