incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Michalski <>
Subject Re: Repair does not fix inconsistency
Date Fri, 05 Apr 2013 10:59:24 GMT
Little update ;-)

It couldn't be so easy - I can't drop these indexes :P

1) cqlsh:

cqlsh:production> DROP INDEX Users_
Users_active_idx    Users_email_idx     Users_username_idx
cqlsh:production> DROP INDEX Users_email_idx ;
cqlsh:production> DROP INDEX Users_
Users_active_idx    Users_email_idx     Users_username_idx

2) cli:

[default@production] drop index on;

So both tools pretend to do what I expect them to do, but indexes are 
still there...

The funny thing is that I can drop these indexes using both - cli and 
cqlsh - when testing  it on my workstation. D'oh! ;-)


W dniu 04.04.2013 16:07, Michal Michalski pisze:
> W dniu 04.04.2013 15:38, horschi pisze:
>> I'm glad to hear that. I feared my ticket might be responsible for your
>> data loss. I could not live the guilt ;-) Seriously: I'm glad we can rule
>> out the repair change.
> Haha, I didn't notice before that it was your ticket! ;-)
>> Yes, if it works with CL=one, then it must be the index. Check the
>> mailing-list, I think someone else posted something similar the other
>> day.
> That was the first thing I checked yesterday, but, as I was not sure if
> that's the problem, I didn't pay too much attention to this ;-) I'll dig
> a bit more then. And I'll probably drop/recreate indexes tomorrow, as a
> "lest resort" if I don't find anything interesting :-)
> Thanks for help :-)
> BTW. there's still a question why CQL requests two nodes when using
> CL=ONE ;-) OK, I have read_repair_chance = 1.0 for this CF, so I might
> assume that tracing in cqlsh somehow "hacks" read_repair and also shows
> all "background" digest requests, but - still - if it matters, it should
> matter for index-based queries too, but it doesn't. Well, it's not my
> biggest problem today, so the answer can wait ;-)
> M.

View raw message