e getting a lot of timeouts you will almost certainly end up with
> consistency issues. You're going to need to fix the root cause, your
> cluster instability, or this sort of issue will be commonplace.
>
>
> On Tue, Feb 14, 2017 at 1:43 PM Josh England wrote:
>
>> I&#x
I'm sorry, yes. The primary key is (foo_prefix, foo), with foo_prefix
being the partition key. The query is:
select * from table WHERE foo_prefix='blah';
-JE
nt from my iPhone
>
> On 14 Feb 2017, at 22:37, Josh England wrote:
>
> All client interactions are from python (python-driver 3.7.1) using
> default consistency (LOCAL_ONE I think). Should I try repairing all nodes
> to make sure all data is consistent?
>
> -JE
>
>
&
;t respond in
> time those records seem to get dropped.
>
> On Tue, Feb 14, 2017 at 1:37 PM Josh England wrote:
>
>> All client interactions are from python (python-driver 3.7.1) using
>> default consistency (LOCAL_ONE I think). Should I try repairing all nodes
>> to mak
ads/writes?
>
> Sent from my iPhone
>
> > On 14 Feb 2017, at 22:27, Josh England wrote:
> >
> > I'm running Cassandra 3.9 on CentOS 6.7 in a 6-node cluster. I've got a
> situation where the same query sometimes returns 2 records (correct), and
> sometimes only
I'm running Cassandra 3.9 on CentOS 6.7 in a 6-node cluster. I've got a
situation where the same query sometimes returns 2 records (correct), and
sometimes only returns 1 record (incorrect). I've ruled out the
application and the indexing since this is reproducible directly from a
cqlsh shell wit
