Cql select queries are returning 0 rows even though the data is actually
available in sstables.
But when i load/restore the same data with sstable loader data can be
queried without any issues.
Am using network topology strategy for all keyspace.
Thanks
On Fri, 15 Mar 2019 at 12:11 PM, Rahul
Can you define "inconsistent" results.. ? What's the topology of the
cluster? What were you expecting and what did you get?
On Thu, Mar 14, 2019 at 7:09 AM sandeep nethi
wrote:
> Hello,
>
> Does anyone experience inconsistent results after restoring Cassandra
> 3.11.1 with refresh command? Was t
Change your consistency levels in the cqlsh shell while you query, from ONE
to QUORUM to ALL. If you see your results change that's a consistency
issue. (Assuming these are simple inserts, if there's deletes, potentially
update collections, etc. in the mix then things get a bit more complex.)
To d
I suspect this is true, but it has proven to be significantly harder to
track down. Either cassandra is tickling some bug that nothing else does
or something strange is going on internally. On an otherwise quiet system,
I'd see instant results most of the time intermixed with queries (reads)
that
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
Well, if it's the primary key there should only ever be one result. Is this
the partition key and you also have a clustering key?
On Tue, Feb 14, 2017 at 1:43 PM Josh England wrote:
> Super simple:
> select * from table WHERE primary_key='foo';
>
> -JE
>
>
> On Tue, Feb 14, 2017 at 1:38 PM, sfes
A little of python code also would help to debug;
query = SimpleStatement(
consistency_level=ConsistencyLevel.ANY)
On 14-02-2017 21:43, Josh England wrote:
> I'll try it the repair. Using quorum tends to lead to too many
> timeout problems though. :(
>
> -JE
>
>
> On Tue, Feb 1
If you're 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'll try it the repair. Using quo
I'll try it the repair. Using quorum tends to lead to too many timeout
problems though. :(
-JE
On Tue, Feb 14, 2017 at 1:39 PM, Oskar Kjellin
wrote:
> Repair might help. But you will end up in this situation again unless you
> read/write using quorum (may be local)
>
> Sent from my iPhone
>
Super simple:
select * from table WHERE primary_key='foo';
-JE
On Tue, Feb 14, 2017 at 1:38 PM, sfesc...@gmail.com
wrote:
> What is your query? I've seen this once when using secondary indices as it
> has to reach out to all nodes for the answer. If a node doesn't respond in
> time those recor
Repair might help. But you will end up in this situation again unless you
read/write using quorum (may be local)
Sent 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
What is your query? I've seen this once when using secondary indices as it
has to reach out to all nodes for the answer. If a node doesn'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-driv
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
On Tue, Feb 14, 2017 at 1:32 PM, Oskar Kjellin
wrote:
> What consistency levels are you using for reads/writes
What consistency levels are you using for reads/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
Hi Jaydeep.
> Now when I read using quorum then sometimes it returns data D1 and
> sometimes it returns empty results. After tracing I found that when N1 and
> N2 are chosen then we get empty data, when (N1/N2) and N3 are chosen then
> D1 data is returned.
This is an acceptable situation (ie. a
Hi Jaydeep,
Yes, dealing with tombstones in Cassandra is very tricky.
Cassandra keeps tombstones to mark deleted columns and distribute (hinted
handoff, full repair, read repair ...) to the other nodes that missed the
initial remove request. But Cassandra can't afford to keep those tombstones
lif
2011/5/23 Jonathan Ellis :
>> It was installed as 0.7.2 and upgraded with each new official release.
>
> I bet that's the problem, then.
> https://issues.apache.org/jira/browse/CASSANDRA-2244 could cause
> indexes to not be updated for releases < 0.7.4. You'll want to
> rebuild the index.
>
>> By
On Mon, May 23, 2011 at 5:47 AM, Wojciech Pietrzok wrote:
> It was installed as 0.7.2 and upgraded with each new official release.
I bet that's the problem, then.
https://issues.apache.org/jira/browse/CASSANDRA-2244 could cause
indexes to not be updated for releases < 0.7.4. You'll want to
rebui
It was installed as 0.7.2 and upgraded with each new official release.
As I wrote in another message in this thread, now nodes are upgraded
to 0.7.6 but it still seems that one of the problematic nodes returns
inconsistent data.
By the way - is it possible to force the rebuild of the secondary
ind
I've already tried running nodetool repair severail times before but
it didn't seem to help.
Now I've upgraded Cassandra to 0.7.6, run nodetool scrub, and nodetool
repair (twice). One of the problematic nodes seems to return correct
results now. But the second one still returns inconsistent data.
Has this cluster always been on 0.7.5 or was it upgraded from an
earlier version?
On Thu, May 19, 2011 at 3:26 AM, Wojciech Pietrzok wrote:
> Just checked. Seems to be present in CF on all nodes (in both
> datacenters), but are not indexed correctly
>
> On each node I've used sstablekeys for all
I am wondering if running nodetool repair will help in anyway
--
View this message in context:
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Inconsistent-results-using-secondary-indexes-between-two-DC-tp632p6382819.html
Sent from the cassandra-u...@incubator.apache.org mail
Just checked. Seems to be present in CF on all nodes (in both
datacenters), but are not indexed correctly
On each node I've used sstablekeys for all CF_NAME-f-XX-Data.db files.
In cassandra-cli I've (using node that behaves correctly) made query
get CF_NAME where foo = bar, got correct number of r
Nothing comes to mind.
I'd start by using sstable2json to see if the missing rows are in the
main data CF -- i.e., are they just unindexed, or are they missing
completely?
On Sun, May 15, 2011 at 4:33 PM, Wojciech Pietrzok wrote:
> Hello,
>
> I've noticed strange behaviour of Cassandra when usin
24 matches
Mail list logo
