Re: 3.11.2 memory leak

Likely in the next few weeks. On Mon., 23 Jul. 2018, 01:17 Abdul Patel, wrote: > Any idea when 3.11.3 is coming in? > > On Tuesday, June 19, 2018, kurt greaves wrote: > >> At this point I'd wait for 3.11.3. If you can't, you can get away with >> backporting a few repair

Re: Limitations of Hinted Handoff OverloadedException exception

The coordinator will refuse to send writes/hints to a node if it has a large backlog of hints (128 * #cores) already and the destination replica is one of the nodes with hints destined to it. It will still send writes to any "healthy" node (a node with no outstanding hints). The idea is to not

Re: Recommended num_tokens setting for small cluster

For 10 nodes you probably want to use between 32 and 64. Make sure you use the token allocation algorithm by specifying allocate_tokens_for_keyspace On Thu., 30 Aug. 2018, 04:40 Jeff Jirsa, wrote: > 3.0 has a (optional?) feature to guarantee better distribution, and the > blog focuses on 2.2. >

[ANNOUNCE] LDAP Authenticator for Cassandra

We've seen a need for an LDAP authentication implementation for Apache Cassandra so we've gone ahead and created an open source implementation (ALv2) utilising the pluggable auth support in C*. Now, I'm positive there are multiple implementations floating around that haven't been open sourced,

Re: default_time_to_live vs TTL on insert statement

The Datastax documentation is wrong. It won't error, and it shouldn't. If you want to fix that documentation I suggest contacting Datastax. On 11 July 2018 at 19:56, Nitan Kainth wrote: > Hi DuyHai, > > Could you please explain in what case C* will error based on documented > statement: > > You

Re: Cassandra 2.1.18 - Concurrent nodetool repair resulting in > 30K SSTables for a single small (GBytes) CF

> > What we did have was some sort of overlapping between our daily repair > cronjob and the newly added node still in progress joining. Don’t know if > this sort of combination might causing troubles. I wouldn't be surprised if this caused problems. Probably want to avoid that. with waiting a

Re: One time major deletion/purge vs periodic deletion

The important point to consider is whether you are deleting old data or recently written data. How old/recent depends on your write rate to the cluster and there's no real formula. Basically you want to avoid deleting a lot of old data all at once because the tombstones will end up in new SSTables

Re: Right sizing Cassandra data nodes

The problem with higher densities is operations, not querying. When you need to add nodes/repair/do any streaming operation having more than 3TB per node becomes more difficult. It's certainly doable, but you'll probably run into issues. Having said that, an insert only workload is the best

Re: The home page of Cassandra is mobile friendly but the link to the third parties is not

Already addressed in CASSANDRA-14128 , however waiting on review/comments regarding what we actually do with this page. If you want to bring attention to JIRA's, user list is probably appropriate. I'd avoid spamming it too much though. On 26

Re: Best way to Drop Tombstones/after GC Grace

At least set GCGS == max_hint_window_in_ms that way you don't effectively disable hints for the table while your compaction is running. Might be preferable to use nodetool garbagecollect if you don't have enough disk space for a major compaction. Also worth noting you should do a splitting major

Re: Removing initial_token parameter

correct, tokens will be stored in the nodes system tables after the first boot, so feel free to remove them (although it's not really necessary) On 9 Mar. 2018 20:16, "Mikhail Tsaplin" wrote: > Is it safe to remove initial_token parameter on a cluster created by > snapshot

Re: Cassandra/Spark failing to process large table

Note that read repairs only occur for QUORUM/equivalent and higher, and also with a 10% (default) chance on anything less than QUORUM (ONE/LOCAL_ONE). This is configured at the table level through the dclocal_read_repair_chance and read_repair_chance settings (which are going away in 4.0). So if

Re: What versions should the documentation support now?

> > I’ve never heard of anyone shipping docs for multiple versions, I don’t > know why we’d do that. You can get the docs for any version you need by > downloading C*, the docs are included. I’m a firm -1 on changing that > process. We should still host versioned docs on the website however.

Re: Shifting data to DCOS

Without looking at the code I'd say maybe the keyspaces are displayed purely because the directories exist (but it seems unlikely). The process you should follow instead is to exclude the system keyspaces for each node and manually apply your schema, then upload your CFs into the correct

Re: Many SSTables only on one node

If there were no other messages about anti-compaction similar to: > > SSTable YYY (ranges) will be anticompacted on range [range] Then no anti-compaction needed to occur and yes, it was not the cause. On 5 April 2018 at 13:52, Dmitry Simonov wrote: > Hi, Evelyn! > >

Re: Token range redistribution

A new node always generates more tokens. A replaced node using replace_address[_on_first_boot] will reclaim the tokens of the node it's replacing. Simply removing and adding back a new node without replace address will end up with the new node having different tokens, which would mean data loss in

Re: Token range redistribution

That's assuming your data is perfectly consistent, which is unlikely. Typically that strategy is a bad idea and you should avoid it. On Thu., 19 Apr. 2018, 07:00 Richard Gray, <richard.g...@smxemail.com> wrote: > On 2018-04-18 21:28, kurt greaves wrote: > > replacing. Simply remo

Re: SSTable count in Nodetool tablestats(LevelCompactionStrategy)

I'm currently investigating this issue on one of our clusters (but much worse, we're seeing >100 SSTables and only 2 in the levels) on 3.11.1. What version are you using? It's definitely a bug. On 17 April 2018 at 10:09, wrote: > Dear Community, > > > > One of the tables

Re: Memtable type and size allocation

Hi Vishal, In Cassandra 3.11.2, there are 3 choices for the type of Memtable > allocation and as per my understanding, if I want to keep Memtables on JVM > heap I can use heap_buffers and if I want to store Memtables outside of JVM > heap then I've got 2 options offheap_buffers and

Re: about the tombstone and hinted handoff

I don't think that's true/maybe that comment is misleading. Tombstones AFAIK will be propagated by hints, and the hint system doesn't do anything to check if a particular row has been tombstoned. To the node receiving the hints it just looks like it's receiving a bunch of writes, it doesn't know

Re: Shifting data to DCOS

Sorry for the delay. > Is the problem related to token ranges? How can I find out token range for > each node? > What can I do to further debug and root cause this? Very likely. See below. My previous cluster has 3 nodes but replication factor is 2. I am not > exactly sure how I would handle

Re: Phantom growth resulting automatically node shutdown

This was fixed (again) in 3.0.15. https://issues.apache.org/jira/browse/CASSANDRA-13738 On Fri., 20 Apr. 2018, 00:53 Jeff Jirsa, wrote: > There have also been a few sstable ref counting bugs that would over > report load in nodetool ring/status due to overlapping normal and >

Re: Execute an external program

Correct. Note that both triggers and CDC aren't widely used yet so be sure to test. On 28 March 2018 at 13:02, Earl Lapus wrote: > > On Wed, Mar 28, 2018 at 8:39 AM, Jeff Jirsa wrote: > >> CDC may also work for newer versions, but it’ll happen after the

Re: auto_bootstrap for seed node

Setting auto_bootstrap on seed nodes is unnecessary and irrelevant. If the node is a seed it will ignore auto_bootstrap and it *will not* bootstrap. On 28 March 2018 at 15:49, Ali Hubail wrote: > "it seems that we still need to keep bootstrap false?" > > Could you shed

Re: replace dead node vs remove node

Didn't read the blog but it's worth noting that if you replace the node and give it a *different* ip address repairs will not be necessary as it will receive writes during replacement. This works as long as you start up the replacement node before HH window ends.

Re: Nodetool Repair --full

Worth noting that if you have racks == RF you only need to repair one rack to repair all the data in the cluster if you *don't* use -pr. Also note that full repairs on >=3.0 case anti-compactions and will mark things as repaired, so once you start repairs you need to keep repairing to ensure you

Re: Cassandra 2.1.18 - Concurrent nodetool repair resulting in > 30K SSTables for a single small (GBytes) CF

Repairs with vnodes is likely to cause a lot of small SSTables if you have inconsistencies (at least 1 per vnode). Did you have any issues when adding nodes, or did you add multiple nodes at a time? Anything that could have lead to a bit of inconsistency could have been the cause. I'd probably

Re: C* in multiple AWS AZ's

There is a need for a repair with both DCs as rebuild will not stream all replicas, so unless you can guarantee you were perfectly consistent at time of rebuild you'll want to do a repair after rebuild. On another note you could just replace the nodes but use GPFS instead of EC2 snitch, using the

Re: Re: stream failed when bootstrap

Best off trying a rolling restart. On 28 June 2018 at 03:18, dayu wrote: > the output of nodetool describecluster > Cluster Information: > Name: online-xxx > Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch > Partitioner: org.apache.cassandra.dht.Murmur3Partitioner > Schema versions:

Re: Re: Re: stream failed when bootstrap

cassandra and start cassandra command one by one, right? > Only one node is executed at a time > > Dayu > > > > At 2018-06-28 11:37:43, "kurt greaves" wrote: > > Best off trying a rolling restart. > > On 28 June 2018 at 03:18, dayu wrote: > >> the outpu

Re: C* in multiple AWS AZ's

status would report rack of 1a, even though in 1e? > > Thanks in advance for the help/thoughts!! > > > On Thu, Jun 28, 2018 at 6:20 PM, kurt greaves > wrote: > >> There is a need for a repair with both DCs as rebuild will not stream all >> replicas, so unles

[ANNOUNCE] StratIO's Lucene plugin fork

Hi all, We've had confirmation from Stratio that they are no longer maintaining their Lucene plugin for Apache Cassandra. We've thus decided to fork the plugin to continue maintaining it. At this stage we won't be making any additions to the plugin in the short term unless absolutely necessary,

Re: Tombstone removal optimization and question

Yes it does. Consider if it didn't and you kept writing to the same partition, you'd never be able to remove any tombstones for that partition. On Tue., 6 Nov. 2018, 19:40 DuyHai Doan Hello all > > I have tried to sum up all rules related to tombstone removal: > > >

Re: SSTableMetadata Util

Pranay, 3.11.3 should include all the C* binaries in /usr/bin. Maybe try reinstalling? Sounds like something got messed up along the way. Kurt On Tue, 2 Oct 2018 at 12:45, Pranay akula wrote: > Thanks Christophe, > > I have installed using rpm package I actually ran locate command to find >

Re: stuck with num_tokens 256

If you have problems with balance you can add new nodes using the algorithm and it'll balance out the cluster. You probably want to stick to 256 tokens though. To reduce your # tokens you'll have to do a DC migration (best way). Spin up a new DC using the algorithm on the nodes and set a lower

Re: stuck with num_tokens 256

new clusters which i'm going to > setup? > Is the Allocation algorithm, now recommended algorithm and mature enough > to replace the Random algorithm? if its so, it should be the default one at > 4.0? > > > On Sat, 22 Sep 2018 13:41:47 +0330 *kurt greaves > >* wrote

Re: stuck with num_tokens 256

No, that's not true. On Sat., 22 Sep. 2018, 21:58 onmstester onmstester, wrote: > > If you have problems with balance you can add new nodes using the > algorithm and it'll balance out the cluster. You probably want to stick to > 256 tokens though. > > > I read somewhere (don't remember the ref)

Re: TWCS + subrange repair = excessive re-compaction?

Not any faster, as you'll still have to wait for all the SSTables to age off, as a partition level tombstone will simply go to a new SSTable and likely will not be compacted with the old SSTables. On Tue, 25 Sep 2018 at 17:03, Martin Mačura wrote: > Most partitions in our dataset span one or

Re: node replacement failed

I don't like your cunning plan. Don't drop the system auth and distributed keyspaces, instead just change them to NTS and then do your replacement for each down node. If you're actually using auth and worried about consistency I believe 3.11 has the feature to be able to exclude nodes during a

<    1   2   3   4