I'll add that while we don't see either of the nodes with the range
that failed marked as down one of them *does* appear to have a late
arrival of the cluster of UP messages that happens just after the
bootstrap fails:
$ egrep 'JOIN|Illegal|10.11.12.14|10.11.12.13' system.log | grep -v ^DEBUG
IN
Neither of the two nodes identified as having the range that
IllegalStateException reports are mentioned by FailureDetector.java.
There are 5 endpoints that FailureDetector says are 'unknown endpoint'
but all of them are reported as "UP" by Gossiper.java before the
"schema complete, ready to boots
Thanks, Mark, this was exactly what I needed!
On Thu, Aug 14, 2014 at 11:54 PM, Mark Reddy wrote:
> Hi Clint,
>
> You need to configure the datastax-agents so they know what machine
> OpsCenter is running on. To do this you will need to edit the address.yaml
> of the datastax-agent, located in /v
The write performance of INSERT or UPDATE is very high in C*, but if you
update too often the row you update frequently will be in many SSTables so
the read latency and system load will be increased until these SSTables are
compacted into one single file.
I think you can use redis (or memcache) to
Check that: https://issues.apache.org/jira/browse/CASSANDRA-6602
There is a patch for a compaction strategy dedicated to time series data.
The discussion is also interesting in the comments.
On Fri, Aug 15, 2014 at 6:28 AM, Kevin Burton wrote:
> We use log structured tables to hold logs for
Hi Peter,
At the time of the IllegalStateException, do you see the node that it
should be streaming from marked as down by the failure detector?
Mark
On Fri, Aug 15, 2014 at 5:45 AM, Peter Haggerty
wrote:
> When adding nodes via bootstrap to a 27 node 2.0.9 cluster with a
> cluster-wide phi_
