Re: Want inputs about super column family vs map/list

Hmm, I have same issue. I would like to know how you are able migrating data from RDBMS to cassandra in this way., i.e. making column's value as column name. Are you using some programming script or datastax scoop support for this?

Atomic Batch: Maintaining consistency between tables

Hello, I read in the documentation DataStax : "The coordinator node might also need to work hard to process a logged batch while maintaining consistency between tables" It means that the coordinator send the mutations to all replica nodes and waits for RF acknowledgements ? or only one node

Re: Duplicated key with an IN statement

Hi, This is interesting. It seems rational that if you are looking at 2 keys and both exist (which is the case) it returns you 2 keys, it. Yet, I just checked this kind of command on MySQL and it gives a one line result. So here CQL differs from SQL (at least MySQL). I know we are trying to fit

Want inputs about super column family vs map/list

Hi All, There are two ways to achieve this : 1. Using super column family: raman | atul | bhuvan --- 1234 | 5678 | 2345 OR Using single Collection column : Phone Number --- Map I would like to know which

Re: "Not enough replicas available for query" after reboot

Hey Flavien! Did your reboot come with any other changes (schema, configuration, topology, version)? On Thu, Feb 4, 2016 at 2:06 PM, Flavien Charlon wrote: > I'm using the C# driver 2.5.2. I did try to restart the client > application, but that didn't make any

Re: Any tips on how to track down why Cassandra won't cluster?

Hi Richard, I think you just can't use EC2Snitch with public IPs. See https://docs.datastax.com/en/cassandra/2.0/cassandra/architecture/architectureSnitchEC2_t.html Precisely "Because private IPs are used, this snitch does not work across multiple regions" 54.*.*.* looks like a public one.

Re: "Not enough replicas available for query" after reboot

On Thu, Feb 4, 2016 at 12:53 PM, Flavien Charlon wrote: > My cluster was running fine. I rebooted all three nodes (one by one), and > now all nodes are back up and running. "nodetool status" shows UP for all > three nodes on all three nodes: > > -- AddressLoad

RE: "Not enough replicas available for query" after reboot

What client are you using? It is possible that the client saw nodes down and has kept them marked that way (without retrying). Depending on the client, you may have options to set in RetryPolicy, FailoverPolicy, etc. A bounce of the client will probably fix the problem for now. Sean Durity

Re: "Not enough replicas available for query" after reboot

No, there was no other change. I did run "apt-get upgrade" before rebooting, but Cassandra has not been upgraded. On 4 February 2016 at 22:48, Bryan Cheng wrote: > Hey Flavien! > > Did your reboot come with any other changes (schema, configuration, > topology, version)? >

System block cache vs. disk access and metrics

We struggled for a while to upgrade due to an out of order SStables bug. During this time, load continued to increase and we were eventually accessing the disk a lot. When we could finally expand the cluster, the went down by an order of magnitude. This leads me to conclude that we had blown

Re: "Not enough replicas available for query" after reboot

Yes, all three nodes see all three nodes as UN. Also, connecting from a local Cassandra machine using cqlsh, I can run the same query just fine (with QUORUM consistency level). On 4 February 2016 at 21:02, Robert Coli wrote: > On Thu, Feb 4, 2016 at 12:53 PM, Flavien

Re: Clustering key values not distributed

Hi Ralf, I am not familiar with the "columnspec" but I'll try to help. First, are you sure that the result is not the one expected ? Did you try a select query specifying a partition key, to check the number of rows returned ? Partitions aren't ordered when fetched, so something like the query

How to migrate MYSQL to cassandra -special case in scoop+datastax

MySQL Table: User | PhoneNumber raman1234 bhuvan 2345 atul 5678 Using single Collection column and map collection : Phone Number --- Map Want to transform data in this way, i.e. key is

Re: "Not enough replicas available for query" after reboot

Are you able to run queries using cqlsh with consistency ALL? On Feb 4, 2016, at 6:32 PM, Flavien Charlon > wrote: No, there was no other change. I did run "apt-get upgrade" before rebooting, but Cassandra has not been upgraded. On 4

Re: "Not enough replicas available for query" after reboot

Yes, that works with consistency ALL. I restarted one of the Cassandra instances, and seems it's working again now. I'm not sure what happened. On 4 February 2016 at 23:48, Peddi, Praveen wrote: > Are you able to run queries using cqlsh with consistency ALL? > > On Feb 4,

Re: Atomic Batch: Maintaining consistency between tables

Hi, The coordinator will send mutations to all required replicas and wait for required acknowledgements to fulfil consistency level. Regards Carlos Alonso | Software Engineer | @calonso On 4 February 2016 at 11:56, wrote: > Hello, > > > >

RE: Duplicated key with an IN statement

Hello, When running that kind of query with TRACING ON; I noticed the coordinator is also performing multiple time the same query Because the element in the IN statement can involve many nodes, it makes sense to map/reduce the query, but running multiple time the same sub query should not

Re: Duplicated key with an IN statement

That behavior has been changed in 2.2 and upwards. If you don't like it, upgrade. In the meantime, it's probably not hard to avoid passing duplicate keys in IN. On Thu, Feb 4, 2016 at 3:48 PM, Edouard COLE wrote: > Hello, > > > > When running that kind of query with

Restart Cassandra automatically

Hi, What is the best way to keep cassandra running? My requirement is if for some reason cassandra stops then it should get started automatically. I tried to achieve this by adding cassandra to supervisord. My supervisor conf for cassandra looks like below:- [program:cassandra]

Re: Duplicated key with an IN statement

Sylvain, there's a bug in CHANGES.TXT for this issue. It says: "Duplicate rows returned when in clause has repeated values (CASSANDRA-6707)", but the issue number is really 6706. -- Jack Krupansky On Thu, Feb 4, 2016 at 9:54 AM, Sylvain Lebresne wrote: > That behavior has

Re: Duplicated key with an IN statement

You shouldn’t be using IN anyway. It is better to issue multiple queries, each for a single key, and issue them in parallel. Better performance. Less GC pressure. On Feb 4, 2016, at 7:54 AM, Sylvain Lebresne > wrote: That behavior has been

Re: Any tips on how to track down why Cassandra won't cluster?

Along the lines of what Ben and Bryan suggested, what are you using to verify ports are open? If you do something like: node1$ nc -zv node2 9042 node2$ nc -zv node1 9042 does it succeed from both nodes? Does the first node 'know' that it is a seed? i.e. do you have first node listed in its own

RE: Duplicated key with an IN statement

Thanks :) De : Robert Wille [mailto:rwi...@fold3.com] Envoyé : Thursday, February 04, 2016 4:37 PM À : user@cassandra.apache.org Objet : Re: Duplicated key with an IN statement You shouldn't be using IN anyway. It is better to issue multiple queries, each for a single key, and issue them in

Re: Want inputs about super column family vs map/list

On Thu, Feb 4, 2016 at 2:37 AM, Bhuvan Rawal wrote: > 1. Using super column family: > Super columns have been not-recommended for use for about five years now. =Rob

Re: Duplicated key with an IN statement

On Thu, Feb 4, 2016 at 9:57 AM, Jack Krupansky wrote: > there's a bug in CHANGES.TXT for this issue. It says: "Duplicate rows > returned when in clause has repeated values (CASSANDRA-6707)", but the > issue number is really 6706. > Thanks, I've fixed this. -- Tyler

"Not enough replicas available for query" after reboot

Hi, My cluster was running fine. I rebooted all three nodes (one by one), and now all nodes are back up and running. "nodetool status" shows UP for all three nodes on all three nodes: -- AddressLoad Tokens OwnsHost ID Rack UN xx.xx.xx.xx331.84 GB 1 ?

Duplicated key with an IN statement

Hello, I just discovered this, and I think this is weird: ed@debian:~$ cqlsh 192.168.10.8 Connected to _CLUSTER_ at 192.168.10.8:9160. [cqlsh 4.0.1 | Cassandra 2.0.14.459 | CQL spec 3.1.1 | Thrift protocol 19.39.0] Use HELP for help. cqlsh> USE ks-test ; cqlsh:ks-test> CREATE TABLE t (