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
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
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
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
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
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
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
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
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
