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 CF510CDED for ; Mon, 30 Apr 2012 03:19:20 +0000 (UTC) Received: (qmail 85342 invoked by uid 500); 30 Apr 2012 03:19:18 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 85169 invoked by uid 500); 30 Apr 2012 03:19:18 -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 85147 invoked by uid 99); 30 Apr 2012 03:19:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Apr 2012 03:19:17 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a56.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Apr 2012 03:19:12 +0000 Received: from homiemail-a56.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a56.g.dreamhost.com (Postfix) with ESMTP id C14D2FE063 for ; Sun, 29 Apr 2012 20:18:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=thelastpickle.com; h=from :mime-version:content-type:subject:date:in-reply-to:to :references:message-id; q=dns; s=thelastpickle.com; b=OWZC5LMP+c 1x9JH5pAOld++BmQSVkq0azccDXeOXGMF9vuE3h9tJOCmyCGVw1Qj73aC7x8/0/0 E+GZ0KgNcvFGL9leU3PZsIswZZWLeT0kkzvsem5J5wMLiRxPQe3dGx8tT65+e5QU iXTo1Z4cBfxaPdWeKltkPgW2DMdRhEndU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thelastpickle.com; h=from :mime-version:content-type:subject:date:in-reply-to:to :references:message-id; s=thelastpickle.com; bh=MTJcGFreVQ+9GFVx yXhatHxKRX8=; b=IkW9JpIJQ1g39kZ0qflSz7I2adGv4DOS9TnN8sF9ZbBfhTw8 wvb02oNAOY/BXkaoMFDbJ3tH1ofZFEeK2Sikb8rKwPOGcwyoQvXUM8h+VJq4bazu 8HFdieZ3ZntlhAtFuTK3qNyuGLOaSohR+9B6w7G7iHSsNP691B+MmenGDjQ= Received: from [192.168.1.52] (unknown [203.109.195.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aaron@thelastpickle.com) by homiemail-a56.g.dreamhost.com (Postfix) with ESMTPSA id 4E493FE05B for ; Sun, 29 Apr 2012 20:18:51 -0700 (PDT) From: aaron morton Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_C9269D9D-B63B-4609-9E15-C8769050DCE4" Subject: Re: Bad Request: No indexed columns present in by-columns clause with "equals" operator Date: Mon, 30 Apr 2012 15:19:03 +1200 In-Reply-To: <18392_1335368012_4F98194C_18392_4401_1_9632480C9F82B44294C2302320958E9808420551DA@PUEXCB2F.nanterre.francetelecom.fr> To: user@cassandra.apache.org References: <5256_1335184767_4F954D7F_5256_385_1_9632480C9F82B44294C2302320958E980841FE98C3@PUEXCB2F.nanterre.francetelecom.fr> <29449_1335268765_4F96959D_29449_1424_1_9632480C9F82B44294C2302320958E980842054EDF@PUEXCB2F.nanterre.francetelecom.fr> <15659_1335345423_4F97C10F_15659_4650_15_9632480C9F82B44294C2302320958E9808420550C4@PUEXCB2F.nanterre.francetelecom.fr> <18392_1335368012_4F98194C_18392_4401_1_9632480C9F82B44294C2302320958E9808420551DA@PUEXCB2F.nanterre.francetelecom.fr> Message-Id: X-Mailer: Apple Mail (2.1257) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_C9269D9D-B63B-4609-9E15-C8769050DCE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Check there is a single schema version on the cluster, in the = cassandra-cli use describe cluster; Cheers ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 26/04/2012, at 3:33 AM, mdione.ext@orange.com wrote: > De : mdione.ext@orange.com [mailto:mdione.ext@orange.com] >> Should I understand that when the indexes are finished being built = a) >> the =ABBuilt indexes=BB list should be empty and b) there should be = no pending >> compactions? Because that's exactly what I have now but I still can't >> use the column HBX_FIL_STATUS in the where clause... >=20 > Ok, answering myself a little: it's more strange than that. When = indexes are=20 > finished being built, they appear in the list, and there should be no = compactions=20 > or anything else in =ABnodetool compactionstats=BB, or at least none = related to indexes. >=20 > Also useful: you'll see this type of messages in the system log (if = the log level=20 > is low enough): >=20 > INFO [Creating index: hbx_file_test2.hbx_file_test2_hbx_fil_date_idx] = 2012-04-25 16:04:48,666 SecondaryIndex.java (line 191) Index build of = hbx_file_test2.hbx_file_test2_hbx_fil_date_idx complete >=20 > Now, back to my problem. We have a 6 node cluster in 2 datacenters,=20= > the KS has a CF of 4 (2 in each DC). I created the index in node 1, = but > node 4 did all the work (we have log level down to debug, so we can = see=20 > these kind of things, and also the creation appears in the output of=20= > =ABnodetool compactionstats=BB as noted above). We have seen similar = messages=20 > in 4 nodes, but not all 6. And now we can make the query on any of the = 4=20 > nodes with success. >=20 > But, and of course there's a but, we can't in the other 2, we still=20= > get the error in the subject. And of course we see a difference in=20 > =ABdescribe avatars=BB: we get =ABBuilt indexes: = [HBX_FILE.HBX_FILE_HBX_FIL_STATUS_idx]=BB > for the 4 nodes where the query works, and =ABBuilt indexes: []=BB.=20 >=20 > No surprises there, except that it doesn't make any sense to us.=20 > How to continue? >=20 > -- > Marcos Dione > SysAdmin > Astek Sud-Est > pour FT/TGPF/OPF/PORTAIL/DOP/HEBEX @ Marco Polo > 04 97 12 62 45 - mdione.ext@orange.com >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 --Apple-Mail=_C9269D9D-B63B-4609-9E15-C8769050DCE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Check = there is a single schema version on the cluster, in the cassandra-cli = use

describe = cluster;


Cheers

http://www.thelastpickle.com

On 26/04/2012, at 3:33 AM, mdione.ext@orange.com = wrote:

De : mdione.ext@orange.com = [mailto:mdione.ext@orange.com]
=  Should I understand that when the indexes are finished being built = a)
the =ABBuilt indexes=BB = list should be empty and b) there should be no = pending
compactions? Because = that's exactly what I have now but I still = can't
use the column = HBX_FIL_STATUS in the where clause...

 Ok, = answering myself a little: it's more strange than that. When indexes are =
finished being built, they appear in the list, and there should be = no compactions
or anything else in =ABnodetool compactionstats=BB, = or at least none related to indexes.

 Also useful: you'll = see this type of messages in the system log (if the log level
is low = enough):

INFO [Creating index: = hbx_file_test2.hbx_file_test2_hbx_fil_date_idx] 2012-04-25 16:04:48,666 = SecondaryIndex.java (line 191) Index build of = hbx_file_test2.hbx_file_test2_hbx_fil_date_idx complete

=  Now, back to my problem. We have a 6 node cluster in 2 = datacenters,
the KS has a CF of 4 (2 in each DC). I created the = index in node 1, but
node 4 did all the work (we have log level down = to debug, so we can see
these kind of things, and also the creation = appears in the output of
=ABnodetool compactionstats=BB as noted = above). We have seen similar messages
in 4 nodes, but not all 6. And = now we can make the query on any of the 4
nodes with = success.

 But, and of course there's a but, we can't in the = other 2, we still
get the error in the subject. And of course we see = a difference in
=ABdescribe avatars=BB: we get =ABBuilt indexes: = [HBX_FILE.HBX_FILE_HBX_FIL_STATUS_idx]=BB
for the 4 nodes where the = query works, and =ABBuilt indexes: []=BB.

 No surprises = there, except that it doesn't make any sense to us.
How to = continue?

--
Marcos Dione
SysAdmin
Astek Sud-Est
pour = FT/TGPF/OPF/PORTAIL/DOP/HEBEX @ Marco Polo
04 97 12 62 45 - mdione.ext@orange.com

___= __________________________________________________________________________= ____________________________________________

Ce message et ses = pieces jointes peuvent contenir des informations confidentielles ou = privilegiees et ne doivent donc
pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, = veuillez le signaler
a l'expediteur et le detruire ainsi que les = pieces jointes. Les messages electroniques etant susceptibles = d'alteration,
France Telecom - Orange decline toute responsabilite si = ce message a ete altere, deforme ou falsifie. Merci.

This message = and its attachments may contain confidential or privileged information = that may be protected by law;
they should not be distributed, used or = copied without authorisation.
If you have received this email in = error, please notify the sender and delete this message and its = attachments.
As emails may be altered, France Telecom - Orange is not = liable for messages that have been modified, changed or = falsified.
Thank = you.


= --Apple-Mail=_C9269D9D-B63B-4609-9E15-C8769050DCE4--