Just to add a few additional notes on the in-place replacement.
* We had to remove system.local and system.peers
* Since we remove those system tables, you also have to put
replace_address_first_boot in cassandra-env with the same IP address.
* We also temporarily add the node as a seed to avoid
Here is a tool I worked on to figure out which node to decommission that will
leave you with the most even token balance afterwards.
https://github.com/jdsumsion/vnode-decommission-calculator
Feel free to use or enhance as you desire.
John...
Hello,
Is there a way to determine the size of “duplicate” date? I.E. data that a node
no longer owns after expanding the ring? Data that is removed with a nodetool
cleanup?
Thank you!
Ian Spence
intermediate devops engineer
Global Relay
Hi,
To be honest I've never seen the OOM in action on those instances. My Xmx
was 8GB just like yours and that let me think you have some process that is
competing for memory, is it? Do you have any cron, any backup, anything
that can trick the OOMKiller ?
My unresponsiveness was seconds long.
Hello community,
I'm receiving some strange streaming errors while trying to restore certain
sstables snapshots with sstableloader to a new cluster.
While the cluster is up and running and nodes are communicating with
each other, I can see streams failing to the nodes with no obvious reason
and
On Thu, Dec 6, 2018 at 11:14 AM Riccardo Ferrari wrote:
>
> I had few instances in the past that were showing that unresponsivveness
> behaviour. Back then I saw with iotop/htop/dstat ... the system was stuck
> on a single thread processing (full throttle) for seconds. According to
> iotop that
Alex,
I had few instances in the past that were showing that unresponsivveness
behaviour. Back then I saw with iotop/htop/dstat ... the system was stuck
on a single thread processing (full throttle) for seconds. According to
iotop that was the kswapd0 process. That system was an ubuntu 16.04
After few hours, i just removed the node. done another node decommissioned,
which finished successfully (the writer app was down, so no pressure on the
cluster) Started another node decommission (third), Since didn't have time to
wait for decommissioning to finish, i started the writer
