Re: CASSANDRA-5376: CQL IN clause on last key not working when schema includes set,list or map

Thanks Tyler, for identifying that this can be fixed now. Here is the JIRA ticket : CASSANDRA-12654 : If this is just removing the now obsolete check, then I hope this makes to 3.10 release. Regards, Samba On Fri, Sep 16, 2016 at 1:33 AM, Tyler Hobbs wrote: > That ticket

Re: Is to ok restart DECOMMISION

Also have a look at `nodetool netstats` to check if streaming is progressing or is halted. Cheers, Jens On Fri, Sep 16, 2016 at 3:18 AM Mark Rose wrote: > I've done that several times. Kill the process, restart it, let it > sync, decommission. > > You'll need enough space

Re: Maximum number of columns in a table

I listened to a talk about the new Cassandra 3 file (sstable) format. One takeaway was that the new format supports sparse data better. That is, is you have 2000 columns, but only setting some of the columns, the disk usage will be much less. Cheers, Jens On Thu, Sep 15, 2016 at 10:24 PM Dorian

Re: How Fast Does Information Spread With Gossip?

> Is a minute a reasonable upper bound for most clusters? I have no numbers and I'm sure this differs depending on how large your cluster is. We have a small cluster of around 12 nodes and I statuses generally propagate in under 5 seconds for sure. So, it will definitely be less than 1 minute.

Space Based Purging

Hello All,    Whats the best way to do data purging in C* column families based on size of the table in the disk apart from TTL?   Thanks and regards,-- IB From: Samba To: user@cassandra.apache.org Sent: Friday, 16 September 2016 2:34 PM Subject: Re: CASSANDRA-5376:

large system hint partition

What would be the likely causes of large system hint partitions? Normally large partition warnings are for user defined tables which they are writing large partitions to. In this case, it appears C* is writing large partitions to the system.hints table. Gossip is not backed up. version: C* 2.2.7

Re: How many vnodes should I use for each node in my cluster?

On Fri, Sep 16, 2016 at 11:29 AM, Li, Guangxing wrote: > Hi, > > I have a 3 nodes cluster, each with less than 200 GB data. Currently all > nodes have the default 256 value for num_tokens. My colleague told me that > with the data size I have (less than 200 GB on each

Inconsistent results with Quorum at different times

Hi, We have three node (N1, N2, N3) cluster (RF=3) and data in SSTable as following: N1: SSTable: Partition key K1 is marked as tombstone at time T2 N2: SSTable: Partition key K1 is marked as tombstone at time T2 N3: SSTable: Partition key K1 is valid and has data D1 with lower time-stamp T1

Re: How Fast Does Information Spread With Gossip?

Gossip propagation is generally best modelled by epidemic algorithms. Luckily for us Cassandra's gossip protocol is fairly simply. Cassandra will perform one Gossip Task every second. Within each gossip task it will randomly gossip with another available node in the cluster, it will also

Re: large system hint partition

Hi Erza, Have you a dead node in your cluster? Because the coordinator stores a hint about dead replicas in the local system.hints when a node is dead or didn't respond to a write request. -- Nicolas Le sam. 17 sept. 2016 à 00:12, Ezra Stuetzel a écrit : > What

Re: Inconsistent results with Quorum at different times

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

Re: Space Based Purging

Hi, The only "safe way" to remove data from Cassandra is through tombstones (TTL / Deletes). I am not sure about the problem you are trying to solve here. Maybe could you let us know a bit more about what you are trying to achieve? If you are trying to expire old data using a stable % of the

How many vnodes should I use for each node in my cluster?

Hi, I have a 3 nodes cluster, each with less than 200 GB data. Currently all nodes have the default 256 value for num_tokens. My colleague told me that with the data size I have (less than 200 GB on each node), I should change num_tokens to something like 32 to get better performance, especially