Re: Inconsistencies between two tables if BATCH used

2015-01-16 Thread Michał Łowicki
Done. https://issues.apache.org/jira/browse/CASSANDRA-8636 On Thu, Jan 15, 2015 at 7:46 PM, Robert Coli wrote: > On Thu, Jan 15, 2015 at 9:09 AM, Michał Łowicki > wrote: > >> We were using LOCAL_QUROUM. C* 2.1.2. Two datacenters. We didn't get any >> exceptions while inserts or deletes. BatchQu

keyspace not exists?

2015-01-16 Thread Jason Wee
$ cqlsh 192.168.0.2 9042 Connected to just4fun at 192.168.0.2:9042. [cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native protocol v3] Use HELP for help. cqlsh> DESCRIBE KEYSPACES cqlsh> create keyspace foobar with replication = {'class':'SimpleStrategy', 'replication_factor':3}; errors={}, l

Re: Many really small SSTables

2015-01-16 Thread Eric Stevens
There's another thread going on right now in this list about compactions not happening when they seemingly should. Tyler Hobbs postulates a bug and workaround for it, so maybe try that out, and if that fixes anything for you, certainly let him know. The bug Tyler postulates on is triggered when y

Re: Many really small SSTables

2015-01-16 Thread Roland Etzenhammer
Hi, I overlooked that disussion. Indeed right now those column family has very much write load and only very minimal reads on it (but there are reads). I run compactionstats serveral times over the last days and sometimes a small bunch of tables gets compacted, about 10-15. After that there a

ODBC driver for C* 2.0.xx

2015-01-16 Thread Ngoc Minh VO
Hello, We are trying to connect some BI tools (eg. Tableau) to our NoSQL database running C* v2.0.6. It seems that the latest Datastax's ODBC driver is not compatible with Cassandra v2.xx (but only with v1.xx, i.e. prior CQL3 era): http://www.datastax.com/download#dl-datastax-drivers http://www

Re: ODBC driver for C* 2.0.xx

2015-01-16 Thread Jens-U. Mozdzen
Hi Minh, Zitat von Ngoc Minh VO : Hello, We are trying to connect some BI tools (eg. Tableau) to our NoSQL database running C* v2.0.6. It seems that the latest Datastax's ODBC driver is not compatible with Cassandra v2.xx (but only with v1.xx, i.e. prior CQL3 era): http://www.datastax.co

RE: ODBC driver for C* 2.0.xx

2015-01-16 Thread Ngoc Minh VO
Hello Jens, Thanks for your quick answer. We got the same issue: connection OK, data browsing NOK. I found an ODBC driver compatible CQL3, just released out yesterday by a company named Simba. But it is a commercial product... Best regards, Minh -Original Message- From: Jens-U. Mozd

Re: keyspace not exists?

2015-01-16 Thread Jens Rantil
Hi Jason, Have you checked the Cassandra log? Cheers, Jens On Fri, Jan 16, 2015 at 10:59 AM, Jason Wee wrote: > $ cqlsh 192.168.0.2 9042 > Connected to just4fun at 192.168.0.2:9042. > [cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native protocol v3] > Use HELP for help. > cqlsh> DESCRIBE K

Re: keyspace not exists?

2015-01-16 Thread Julien Anguenot
Hey Jason, Your RF=3, do you have 3 nodes up and running in this DC? We have seen this issue with 2.1.x and cqlsh where schema changes would trigger the "keyspace not found" error in cqlsh if not all nodes were up and running when altering KS schema in a DC with NetworkTopologyStrategy and RF=3. F

Retrieving all row keys of a CF

2015-01-16 Thread Ruchir Jha
We have a column family that has about 800K rows and on an average about a million columns. I am interested in getting all the row keys in this column family and I am using the following Astyanax code snippet to do this. This query never finishes (ran it for 2 days but did not finish). This quer

Re: Inconsistencies between two tables if BATCH used

2015-01-16 Thread Robert Coli
On Fri, Jan 16, 2015 at 12:58 AM, Michał Łowicki wrote: > Done. https://issues.apache.org/jira/browse/CASSANDRA-8636 > Thank you for closing the loop and including the link in your reply. Future searchers will appreciate. =Rob

Re: Retrieving all row keys of a CF

2015-01-16 Thread Eric Stevens
Note that getAllRows() is deprecated in Astyanax (see here ). You should prefer to use the AllRowsReader recipe: https://github.com/Netflix/astyanax/wiki/AllRowsReader-All-rows-query Note the

Re: keyspace not exists?

2015-01-16 Thread Tyler Hobbs
This might be https://issues.apache.org/jira/browse/CASSANDRA-8512 if your cluster has a schema disagreement. You can apply the patch on that ticket with "patch -p1 < 8512-2.1.txt" from the top-level cassandra directory and see if it helps. On Fri, Jan 16, 2015 at 11:58 AM, Julien Anguenot wrote

RE: Retrieving all row keys of a CF

2015-01-16 Thread Mohammed Guller
Ruchir, I am curious if you had better luck with the AllRowsReader recipe. Mohammed From: Eric Stevens [mailto:migh...@gmail.com] Sent: Friday, January 16, 2015 12:33 PM To: user@cassandra.apache.org Subject: Re: Retrieving all row keys of a CF Note that getAllRows() is deprecated in Astyanax (s

Re: Retrieving all row keys of a CF

2015-01-16 Thread Ravi Agrawal
Hi, I and Ruchir tried query using AllRowsReader recipe but had no luck. We are seeing PoolTimeoutException. SEVERE: [Thread_1] Error reading RowKeys com.netflix.astyanax.connectionpool.exceptions.PoolTimeoutException: PoolTimeoutException: [host=servername, latency=2003(2003), attempts=4]Timed

RE: Retrieving all row keys of a CF

2015-01-16 Thread Mohammed Guller
A few questions: 1) What is the heap size and total memory on each node? 2) How big is the cluster? 3) What are the read and range timeouts (in cassandra.yaml) on the C* nodes? 4) What are the timeouts for the Astyanax client? 5) Do you see GC pressure on the C* node

RE: Retrieving all row keys of a CF

2015-01-16 Thread Ravi Agrawal
1)What is the heap size and total memory on each node? 8GB, 8GB 2)How big is the cluster? 4 3)What are the read and range timeouts (in cassandra.yaml) on the C* nodes? 10 secs, 10 secs 4)What are the timeouts for the Astyanax client? 2 secs 5)

RE: Retrieving all row keys of a CF

2015-01-16 Thread Mohammed Guller
Both total system memory and heap size can't be 8GB? The timeout on the Astyanax client should be greater than the timeouts on the C* nodes, otherwise your client will timeout prematurely. Also, have you tried increasing the timeout for the range queries to a higher number? It is not recommende