We have lots of dedicated Cassandra clusters for large use cases, but we
have a long tail of (~100) of internal customers who want to store < 200GB
of data with < 5k qps and non-critical data. It does not make sense to
create a 3 node dedicated cluster for each of these small use cases. So we
have
Hello,
Recently, I started noticing an interesting pattern. When I execute
"removenode", a subset of the nodes that now own the tokens result it in a CPU
spike / disk activity, and sometimes SSTables on those nodes shoot up.
After looking through the code, it appears to me that below function f
Every topology operation tries to respect/restore the RF except for
assassinate.
On Wed, Feb 22, 2017 at 12:45 PM, Anubhav Kale <
anubhav.k...@microsoft.com.invalid> wrote:
> Hello,
>
> Recently, I started noticing an interesting pattern. When I execute
> "removenode", a subset of the nodes that
But I don't understand how the replica count is getting restored here. The node
that invoked removenode only owns partial ranges.
-Original Message-
From: Brandon Williams [mailto:dri...@gmail.com]
Sent: Wednesday, February 22, 2017 10:49 AM
To: dev@cassandra.apache.org
Subject: Re: Remo
The node that invoked removenode is entirely irrelevant, any node can
invoke it.
On Wed, Feb 22, 2017 at 12:51 PM, Anubhav Kale <
anubhav.k...@microsoft.com.invalid> wrote:
> But I don't understand how the replica count is getting restored here. The
> node that invoked removenode only owns partia
Nevermind. I figured out this is happening on all nodes where the tokens got
moved. So, explains the big streaming going around in the cluster.
-Original Message-
From: Brandon Williams [mailto:dri...@gmail.com]
Sent: Wednesday, February 22, 2017 10:53 AM
To: dev@cassandra.apache.org
Sub
Hi Folks,
I am trying to read Mutations from commit log files through an
implementation of CommitLogReadHandler interface.
For a truncate CQL operation, I do not see a Mutation object.
Does C* skip writing the truncate operation into the commit log file?
Thanks for your help.
Best regards,
Sa
Everything in that table is deleted. There's no mutation or anything in the
commitlog. It's a deletion of all the sstables for that table. To make sure
everything is gone, it first does a flush, then a snapshot to protect against a
mistake, then the truncate itself.
> On Feb 22, 2017, at 6:05 P
Thanks Jeremy.
Any way I could detect that such a truncate operation was performed on the
table? Does it leave a trace that the truncate happened anywhere?
Best regards,
Sanal
On Thu, Feb 23, 2017 at 11:47 AM, Jeremy Hanna
wrote:
> Everything in that table is deleted. There's no mutation or an
