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.000000+0000 | 22 | src1 | dst1
>
> (1 rows)
> cqlsh:test>
>
> Did you use CQLSH to reproduce the problem or another client?
>
>
