Re: unexpected select result on secondary index on static column
Micha,
I did not had the time to look into your problem yet.
Could you open a JIRA ticket to be sure that we do not forget about this
problem? I will look into it as soon as I can.
On Mon, Jan 30, 2017 at 5:12 PM, Benjamin Lerer wrote:
> I do not see why you should get that problem with a replication factor of
> 2.
> I will look into it.
>
> On Mon, Jan 30, 2017 at 5:06 PM, Micha wrote:
>
>> OK, thanks, that was good!
>>
>> You have allocated the keyspace with replication factor 3. If I do this
>> it works on my cluster too!
>>
>> If I try this in a new keyspace with replication factor 2 I get the same
>> result as before, nearly at least, this time 58 rows.
>>
>> I can reproduce this: 3-node cluster and replication factor 3 -> it works
>> 3-node cluster and replication factor 2 (or 1) -> wrong result.
>>
>>
>> Are there restrictions on the replication factor? Does this matter as
>> the index is stored locally (as I have read)?
>>
>> I did use cqlsh and also get the same result when using the java api.
>>
>> Thanks for helping,
>> Michael
>>
>>
>> On 30.01.2017 16:50, Benjamin Lerer wrote:
>> > So, far I do not have any sucess in trying to reproduce the problem.
>> > I created a 3 node clusters using 3.9 with ccm and used CQLSH to
>> reproduce
>> > the problem but I only got back one row:
>> >
>> > cqlsh> create KEYSPACE test WITH replication = {'class':
>> 'SimpleStrategy',
>> > 'replication_factor': 3};
>> > cqlsh> use test;
>> > cqlsh:test> create table demo (id text, id2 bigint static, added
>> timestamp,
>> > source
>> > ... text static, dest text, primary key (id, added));
>> > cqlsh:test> create index on demo (id2);
>> > cqlsh:test> insert into demo (id, id2, added, source, dest) values
>> ('id1',
>> > 22,
>> > ... '2017-01-28', 'src1', 'dst1');
>> > cqlsh:test> select * from demo where id2=22;
>> >
>> > id | added | id2 | source | dest
>> > -+-+-++--
>> > id1 | 2017-01-27 23:00:00.00+ | 22 | src1 | dst1
>> >
>> > (1 rows)
>> > cqlsh:test>
>> >
>> > Did you use CQLSH to reproduce the problem or another client?
>> >
>> >
>>
>
>
Re: unexpected select result on secondary index on static column
I do not see why you should get that problem with a replication factor of 2.
I will look into it.
On Mon, Jan 30, 2017 at 5:06 PM, Micha wrote:
> OK, thanks, that was good!
>
> You have allocated the keyspace with replication factor 3. If I do this
> it works on my cluster too!
>
> If I try this in a new keyspace with replication factor 2 I get the same
> result as before, nearly at least, this time 58 rows.
>
> I can reproduce this: 3-node cluster and replication factor 3 -> it works
> 3-node cluster and replication factor 2 (or 1) -> wrong result.
>
>
> Are there restrictions on the replication factor? Does this matter as
> the index is stored locally (as I have read)?
>
> I did use cqlsh and also get the same result when using the java api.
>
> Thanks for helping,
> Michael
>
>
> On 30.01.2017 16:50, Benjamin Lerer wrote:
> > So, far I do not have any sucess in trying to reproduce the problem.
> > I created a 3 node clusters using 3.9 with ccm and used CQLSH to
> reproduce
> > the problem but I only got back one row:
> >
> > cqlsh> create KEYSPACE test WITH replication = {'class':
> 'SimpleStrategy',
> > 'replication_factor': 3};
> > cqlsh> use test;
> > cqlsh:test> create table demo (id text, id2 bigint static, added
> timestamp,
> > source
> > ... text static, dest text, primary key (id, added));
> > cqlsh:test> create index on demo (id2);
> > cqlsh:test> insert into demo (id, id2, added, source, dest) values
> ('id1',
> > 22,
> > ... '2017-01-28', 'src1', 'dst1');
> > cqlsh:test> select * from demo where id2=22;
> >
> > id | added | id2 | source | dest
> > -+-+-++--
> > id1 | 2017-01-27 23:00:00.00+ | 22 | src1 | dst1
> >
> > (1 rows)
> > cqlsh:test>
> >
> > Did you use CQLSH to reproduce the problem or another client?
> >
> >
>
Re: unexpected select result on secondary index on static column
OK, thanks, that was good!
You have allocated the keyspace with replication factor 3. If I do this
it works on my cluster too!
If I try this in a new keyspace with replication factor 2 I get the same
result as before, nearly at least, this time 58 rows.
I can reproduce this: 3-node cluster and replication factor 3 -> it works
3-node cluster and replication factor 2 (or 1) -> wrong result.
Are there restrictions on the replication factor? Does this matter as
the index is stored locally (as I have read)?
I did use cqlsh and also get the same result when using the java api.
Thanks for helping,
Michael
On 30.01.2017 16:50, Benjamin Lerer wrote:
> So, far I do not have any sucess in trying to reproduce the problem.
> I created a 3 node clusters using 3.9 with ccm and used CQLSH to reproduce
> the problem but I only got back one row:
>
> cqlsh> create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> cqlsh> use test;
> cqlsh:test> create table demo (id text, id2 bigint static, added timestamp,
> source
> ... text static, dest text, primary key (id, added));
> cqlsh:test> create index on demo (id2);
> cqlsh:test> insert into demo (id, id2, added, source, dest) values ('id1',
> 22,
> ... '2017-01-28', 'src1', 'dst1');
> cqlsh:test> select * from demo where id2=22;
>
> id | added | id2 | source | dest
> -+-+-++--
> id1 | 2017-01-27 23:00:00.00+ | 22 | src1 | dst1
>
> (1 rows)
> cqlsh:test>
>
> Did you use CQLSH to reproduce the problem or another client?
>
>
Re: unexpected select result on secondary index on static column
So, far I do not have any sucess in trying to reproduce the problem.
I created a 3 node clusters using 3.9 with ccm and used CQLSH to reproduce
the problem but I only got back one row:
cqlsh> create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 3};
cqlsh> use test;
cqlsh:test> create table demo (id text, id2 bigint static, added timestamp,
source
... text static, dest text, primary key (id, added));
cqlsh:test> create index on demo (id2);
cqlsh:test> insert into demo (id, id2, added, source, dest) values ('id1',
22,
... '2017-01-28', 'src1', 'dst1');
cqlsh:test> select * from demo where id2=22;
id | added | id2 | source | dest
-+-+-++--
id1 | 2017-01-27 23:00:00.00+ | 22 | src1 | dst1
(1 rows)
cqlsh:test>
Did you use CQLSH to reproduce the problem or another client?
On Mon, Jan 30, 2017 at 2:39 PM, Benjamin Lerer wrote:
> I will try to reproduce the problem.
> Thanks for the information
>
> On Mon, Jan 30, 2017 at 2:34 PM, Micha wrote:
>
>> I have restarted the three node cluster with new directories for data
>> and commitlog and made the test again.
>>
>> This time the resultset size is 62 rows for the select.
>> If I execute the select often it jumps between 62 and 65 rows.
>>
>> After inserting a second row I get 129 rows back I select using the id2
>> of the new row.
>>
>>
>> I have no idea what the cause is, espacially if it works for you.
>>
>> One thing: cassandra startup log says I should use the newest oracle
>> release instead of openjdk. Is this possibly causing trouble?
>>
>>
>> cheers,
>> Michael
>>
>>
>
Re: unexpected select result on secondary index on static column
I will try to reproduce the problem. Thanks for the information On Mon, Jan 30, 2017 at 2:34 PM, Micha wrote: > I have restarted the three node cluster with new directories for data > and commitlog and made the test again. > > This time the resultset size is 62 rows for the select. > If I execute the select often it jumps between 62 and 65 rows. > > After inserting a second row I get 129 rows back I select using the id2 > of the new row. > > > I have no idea what the cause is, espacially if it works for you. > > One thing: cassandra startup log says I should use the newest oracle > release instead of openjdk. Is this possibly causing trouble? > > > cheers, > Michael > >
Re: unexpected select result on secondary index on static column
I have restarted the three node cluster with new directories for data and commitlog and made the test again. This time the resultset size is 62 rows for the select. If I execute the select often it jumps between 62 and 65 rows. After inserting a second row I get 129 rows back I select using the id2 of the new row. I have no idea what the cause is, espacially if it works for you. One thing: cassandra startup log says I should use the newest oracle release instead of openjdk. Is this possibly causing trouble? cheers, Michael
Re: unexpected select result on secondary index on static column
Sorry, I am not sure that I understand you correctly. Do you see the problem on a one Node cluster or not? On Mon, Jan 30, 2017 at 12:05 PM, Micha wrote: > Hi, > > forget my the last mail. On the single node cluster it works. > > I can try it on the three-node cluster with a keyspace with replication > factor of 1 and see what happens. > I left most of the default config of cassandra untouched, except storage > directories and ip addresses. > > Cheers, > Michael > > > > > > > > On 30.01.2017 10:54, Benjamin Lerer wrote: > > Hi Michael, > > > > It sound like a bug but I could not reproduced it on 3.9 or on the > current > > 3.11 branch (which will become 3.10). > > Now, that does not mean that there are not problem. Something might be > > different in your environement. > > Do you still see that problem when you start from a clean environment > with > > a single node? > > > > Benjamin >
Re: unexpected select result on secondary index on static column
Hi, forget my the last mail. On the single node cluster it works. I can try it on the three-node cluster with a keyspace with replication factor of 1 and see what happens. I left most of the default config of cassandra untouched, except storage directories and ip addresses. Cheers, Michael On 30.01.2017 10:54, Benjamin Lerer wrote: > Hi Michael, > > It sound like a bug but I could not reproduced it on 3.9 or on the current > 3.11 branch (which will become 3.10). > Now, that does not mean that there are not problem. Something might be > different in your environement. > Do you still see that problem when you start from a clean environment with > a single node? > > Benjamin
Re: unexpected select result on secondary index on static column
Hi,
my cluster is quite new, with three (jessie) nodes and only some test
tables with a few rows of data in it.
I just started a fresh one-node-cluster on another machine, created the
table then the second index on the static column and inserted one row of
data.
create table demo (id text, added timestamp, dest text, id2 bigint
static, source text static, primary key (id, added));
create index id2_index on demo (id2);
insert into demo (id, added,dest,id2,source)
values ('id-1', '2017-01-30', 'dest-1', 22, 'source');
select * from demo gives one row
select * from demo where id2 = 22 gives 194 rows(!), all the same.
The only difference is that the replication factor is 1 instead of 2
this time.
If you need more info or logs, I would like to help.
Cheers,
Michael
On 30.01.2017 10:54, Benjamin Lerer wrote:
> Hi Michael,
>
> It sound like a bug but I could not reproduced it on 3.9 or on the
> current 3.11 branch (which will become 3.10).
> Now, that does not mean that there are not problem. Something might be
> different in your environement.
> Do you still see that problem when you start from a clean environment
> with a single node?
>
> Benjamin
Re: unexpected select result on secondary index on static column
Hi Michael,
It sound like a bug but I could not reproduced it on 3.9 or on the current
3.11 branch (which will become 3.10).
Now, that does not mean that there are not problem. Something might be
different in your environement.
Do you still see that problem when you start from a clean environment with
a single node?
Benjamin
On Mon, Jan 30, 2017 at 10:19 AM, Micha wrote:
> Hi,
>
> I have a second index on a static column and I don't
> understand the answer I get from my select.
>
> Maybe someone who understands the inner working of the second index can
> give me a hint on this (cassandra 3.9)
>
> A cut down version of the table is:
>
> create table demo (id text, id2 bigint static, added timestamp, source
> text static, dest text, primary key (id, added));
>
> create index on demo (id2);
>
> id and id2 match one to one.
>
> I make one insert:
> insert into demo (id, id2, added, source, dest) values ('id1', 22,
> '2017-01-28', 'src1', 'dst1');
>
>
> The "select from demo;" gives the expected answer of the one inserted row.
>
> But "select from demo where id2=22" gives 70 rows as result (all the same).
>
> Why? I have read
> https://www.datastax.com/dev/blog/cassandra-native-
> secondary-index-deep-dive
>
> but I don't get it...
>
> thanks for helping
> Michael
>
>
unexpected select result on secondary index on static column
Hi,
I have a second index on a static column and I don't
understand the answer I get from my select.
Maybe someone who understands the inner working of the second index can
give me a hint on this (cassandra 3.9)
A cut down version of the table is:
create table demo (id text, id2 bigint static, added timestamp, source
text static, dest text, primary key (id, added));
create index on demo (id2);
id and id2 match one to one.
I make one insert:
insert into demo (id, id2, added, source, dest) values ('id1', 22,
'2017-01-28', 'src1', 'dst1');
The "select from demo;" gives the expected answer of the one inserted row.
But "select from demo where id2=22" gives 70 rows as result (all the same).
Why? I have read
https://www.datastax.com/dev/blog/cassandra-native-secondary-index-deep-dive
but I don't get it...
thanks for helping
Michael
