-- Forwarded message --
From: Parth Setya
Date: Fri, May 22, 2015 at 5:14 PM
Subject: INFO LOGS NOT written to System.log (Intermittently)
To: user@cassandra.apache.org
Hi
I have a *3 node *cluster.
Logging Level: *INFO*
We observed that for there is nothing written to the syst
We have encountered issues of very long running nodetool repair when we ran it
node by node on really large dataset. It even kept on running for a week in
some cases.
IMO the strategy you are choosing of repairing nodes by –st and –et is good one
and does the same work in small increments logs o
Hi,
For a delete intensive workload ( translate to write intensive), is there
any reason to use leveled compaction ? The recommendation seems to be that
leveled compaction is suited for read intensive workloads.
Depending on your use case, you might better of with data tiered or size
tiered strat
What impact would vnodes have on strong consistency? I think the problem
you're describing exists with or without them.
On Sat, May 23, 2015 at 2:30 PM Nate McCall wrote:
>
>> So my question is: suppose I take a 12 disk JBOD and run 2 Cassandra
>> nodes (each with 5 data disks, 1 commit log dis
Hi all,
I have a question re leveled compaction strategy that has been bugging me
quite a lot lately. Based on what I understood, a compaction takes place
when the SSTable gets to a specific size (10 times the size of its previous
generation). My question is about an edge case where, due to a real
You should use nodetool repair -pr on every node to make sure that each range
is repaired only once.
Thanks
Anuj Wadehra
Sent from Yahoo Mail on Android
From:"Brice Argenson"
Date:Sat, 23 May, 2015 at 12:31 am
Subject:Periodic Anti-Entropy repair
Hi everyone,
We are currently migrating f
