> 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 <aa...@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 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 <k...@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 > > > > > > > > > > >
