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 Users.email;
d8f6c9c4-bbb8-3e73-b46c-54878e069eba
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! ;-)
M.
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.
