Re: Node failure

I’ve had a few use cases for downgrading consistency over the years. If you’re showing a customer dashboard w/ some Ad summary data, it’s great to be right, but showing a number that’s close is better than not being up. > On Oct 6, 2017, at 1:32 PM, Jeff Jirsa wrote: > > I

Re: Node failure

I think it was Brandon that used to make a pretty compelling argument that downgrading consistency on writes was always wrong, because if you can tolerate the lower consistency, you should just use the lower consistency from the start (because cassandra is still going to send the write to all

Ip restriction for username

Hi, Is there some method to restrict a user to specific ip range/mask (MySQL and postgre has this kind of functionality)? I know dse have more advanced authentication like Kerberos and ldap but I don't know whether those can provide this functionality. Thanks

Re: Node failure

> Modern client drivers also have ways to “downgrade” the CL of requests, in > case they fail. E.g. for the Java driver: > http://docs.datastax.com/en/latest-java-driver-api/com/datastax/driver/core/policies/DowngradingConsistencyRetryPolicy.html Quick note from a driver dev's perspective:

RE: Node failure

I’ll check to see what our app is using. Thanks Mark 801-705-7115 office From: Steinmaurer, Thomas [mailto:thomas.steinmau...@dynatrace.com] Sent: Friday, October 6, 2017 12:25 PM To: user@cassandra.apache.org Subject: RE: Node failure QUORUM should succeed with a RF=3 and 2 of 3 nodes

RE: Node failure

QUORUM should succeed with a RF=3 and 2 of 3 nodes available. Modern client drivers also have ways to “downgrade” the CL of requests, in case they fail. E.g. for the Java driver:

RE: Node failure

We are using quorum on our reads and writes. Thanks Mark 801-705-7115 office From: Jeff Jirsa [mailto:jji...@gmail.com] Sent: Friday, October 6, 2017 11:30 AM To: cassandra Subject: Re: Node failure If you write with CL:ANY, CL:ONE (or LOCAL_ONE), and one node fails,

RE: Node failure

Thanks for the detail. I’ll have to remove and then add one back in. It’s my consistency levels that may bite me in the interim. Thanks Mark 801-705-7115 office From: Jeff Jirsa [mailto:jji...@gmail.com] Sent: Friday, October 6, 2017 11:29 AM To: cassandra Subject:

Re: Node failure

If you write with CL:ANY, CL:ONE (or LOCAL_ONE), and one node fails, you may lose data that hasn't made it to other nodes. On Fri, Oct 6, 2017 at 10:28 AM, Mark Furlong wrote: > The only time I’ll have a problem is if I have a do a read all or write > all. Any other

RE: Node failure

The only time I’ll have a problem is if I have a do a read all or write all. Any other gotchas I should be aware of? Thanks Mark 801-705-7115 office From: Akshit Jain [mailto:akshit13...@iiitd.ac.in] Sent: Friday, October 6, 2017 11:25 AM To: user@cassandra.apache.org Subject: Re: Node failure

Re: Node failure

You replace it with a new node and bootstraping happens.The new node receives data from other two nodes. Rest depends on the scenerio u are asking for. Regards Akshit Jain B-Tech,2013124 9891724697 On Fri, Oct 6, 2017 at 10:50 PM, Mark Furlong wrote: > What happens when

Re: Node failure

There's a lot to talk about here, what's your exact question? - You can either remove it from the cluster or replace it. You typically remove it if it'll never be replaced, but in RF=3 with 3 nodes, you probably need to replace it. To replace, you'll start a new server with

Node failure

What happens when I have a 3 node cluster with RF 3 and a node fails that needs to be removed? Mark Furlong Sr. Database Administrator mfurl...@ancestry.com M: 801-859-7427 O: 801-705-7115 1300 W Traverse Pkwy Lehi, UT 84043

Re: Nodes just dieing with OOM

Hi Alain, thanks for getting back to me. I will read through those articles. The truncate did solve the problem. I am using Cassandra 2.1.15 I'll look at cfstats in more detail, we've got some charting from JVM metrics yeah. We're migrating from i2.xl (32GB ram, Local SSD) to m4.xl (16gb, gp2)

DataStax Spark driver performance for analytics workload

Hello, When doing analytics is Spark, a common pattern is to load either the whole table into memory or filter on some columns. This is a good pattern for column-oriented files (Parquet) but seems to be a huge anti-pattern in C*. Most common spark operations will result in one of (a) query

Re: How do TTLs generate tombstones

Hi Eugene, If we never use updates (time series data), is it safe to set > gc_grace_seconds=0. As Kurt pointed, you never want 'gc_grace_seconds' to be lower than 'max_hint_window_in_ms' as the min off these 2 values is used for hints storage window size in Apache Cassandra. Yet time series

Re: Nodes just dieing with OOM

Hello Brian. Sorry to hear, looks like a lot of troubles. I think we should review this column family design so it doesn't generate > so many tombstones? Could that be the cause? It could be indeed, did truncating solved the issue? There so nicer approaches you can try to handle tombstones

Re: Nodes just dieing with OOM

Sorry about that. We eventually found that one column family had some large/corrupt data and causing OOM's Luckily it was a pretty ephemeral data set and we were able to just truncate it. However, it was a guess based on some log messages about reading a large number of tombstones on that

Re: Nodetool Authentication

In this tutorial : https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureNodetool.html In note section it is written "In Cassandra 3.0.8 and later, a user designated readonly access can run nodetool info so that cluster monitoring is available. In earlier versions, the user must

Re: Nodetool Authentication

Which exactly "read access" are you refering to? Can you point out in the tutorial? On fre, 2017-10-06 at 14:03 +0530, Akshit Jain wrote: Hi, For nodetool authentication I'm following this:

Nodes just dieing with OOM

Hi guys, our cluster - around 18 nodes - just starting having nodes die and when restarting them they are dying with OOM. How can we handle this? I've tried adding a couple extra gigs on these machines to help but it's not. Help! -B

Re: Proposal for deprecating/removing the read_repair_chance/dclocal_read_repair_chance table options

Hello Sylvain, Here is my feedback on this: Would +1 deprecating it in 3.11.x and removing in 4.0 > +1, unless someone can present a solid use case indeed. Lastly, if the consensus here ends up being that they can have their use in > weird case and that we fill supporting those cases is worth

Nodetool Authentication

Hi, For nodetool authentication I'm following this: https://support.datastax.com/hc/en-us/articles/204226179-Step-by-step-instructions-for-securing-JMX-authentication-for-nodetool-utility-OpsCenter-and-JConsole