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