So create additional alias IPs and set listen_address and rpc_address to each
of them on corresponding node.
There is also JMX port (7199) that binds to 127.0.0.1 by default. I didn't
check whether C* can start if this port is already busy. If it fails you should
bind it to different IPs as well
Hello,
As part of rebuild, I noticed that the destination node gets -tmp- files from
other nodes. Are following statements correct ?
1. The files are written to disk without going through memtables.
2. Regular compactors eventually compact them to bring down # SSTables to
a reason
Both of your statements are true.
During your decom, you likely streamed LOTs of sstables to the remaining nodes
(especially true if you didn’t drop the replication factor to 0 for the DC you
decommissioned). Since those tens of thousands of sstables take a while to
compact, if you then rebu
Thanks.
We always set RF to 0 and then “removenode” all nodes in the DC that we want to
decom. So, I highly doubt that is the problem. Plus, #SSTables on a given node
on average is ~2000 (we have 140 nodes in one ring and two rings overall).
From: Jeff Jirsa [mailto:jeff.ji...@crowdstrike.com]
We are seeing following warnings in system.log, As
compaction_large_partition_warning_threshold_mb in cassandra.yaml file is as
default value 100, we are seeing these warnings
110:WARN [CompactionExecutor:91798] 2016-10-05 00:54:05,554
BigTableWriter.java:184 - Writing large partition
system
If you set RF to 0, you can ignore my second sentence/paragraph. The third
still applies.
From: Anubhav Kale
Reply-To: "user@cassandra.apache.org"
Date: Wednesday, October 5, 2016 at 1:56 PM
To: "user@cassandra.apache.org"
Subject: RE: Nodetool rebuild question
Thanks.
We always
The only current solution is to truncate it periodically. I opened
https://issues.apache.org/jira/browse/CASSANDRA-12701 about it if
interested in following
On Wed, Oct 5, 2016 at 4:23 PM, Saladi Naidu wrote:
> We are seeing following warnings in system.log, As
> *compaction_large_partition_war
Since some days I have the problem that I cannot run a dtest as jolokia
fails to attach to the process.
It worked some days ago. I tried both on MacOS + Linux with dtest master
and pip'ed requirements.
dtest output is:
Failed to start jolokia agent (command was:
/usr/lib/jvm/oracle-java8-jdk-amd64
Maybe additional information, this is the CS command line for ccm node1:
br 20376 3.2 8.6 2331136 708308 pts/5 Sl 06:10 0:30 java
-Xloggc:/home/br/.ccm/test/node1/logs/gc.log -ea -XX:+UseThreadPriorities
-XX:ThreadPriorityPolicy=42 -XX:+HeapDumpOnOutOfMemoryError -Xss256k
-XX:StringTa
