If possible, prefer m5 over m4, cause they are running on a newer hypervisor
(KVM-based), single core performance is ~ 10% better compared to m4 with m5
even being slightly cheaper than m4.
Thomas
From: Erick Ramirez
Sent: Donnerstag, 30. Jänner 2020 03:00
To: user@cassandra.apache.org
There is no need to shutdown the application because you should be able to
carry out the operating system upgraded without an outage to the database
particularly since you have a lot of nodes in your cluster.
Provided your cluster has sufficient capacity, you might even have the
ability to
Hi Maxim,
Basically what Sean suggested is the way to do this without downtime.
To clarify the, the *three* steps following the "Decommission each node in
the DC you are working on" step should be applied to *only* the
decommissioned nodes. So where it say "*all nodes*" or "*every node*" it
That is some good info. To add just a little more, knowing what the
pending security updates are for your nodes helps in knowing what to do
after. Read the security update notes from your vendor.
Java or Cassandra update? Of course the service needs restarted -
rolling upgrade and restart the
Here is a link to get started with DSBench:
https://github.com/datastax/dsbench-labs#getting-started
and DataStax Labs:
https://downloads.datastax.com/#labs
On Thu, Jan 30, 2020 at 11:47 AM Jonathan Shook wrote:
>
> Some of you may remember NGCC talks on metagener (now VirtualDataSet)
> and
Some of you may remember NGCC talks on metagener (now VirtualDataSet)
and engineblock from 2015 and 2016. The main themes went something
along the lines of "testing c* with realistic workloads is hard,
sizing cassandra is hard, we need tools in this space that go beyond
what cassandra-stress can
Your procedure won’t work very well. On the first node, if you switched to 4,
you would end up with only a tiny fraction of the data (because the other nodes
would still be at 256). I updated a large cluster (over 150 nodes – 2 DCs) to
smaller number of vnodes. The basic outline was this:
*
Hi everyone,
with discussion about reducing default vnodes in version 4.0 I would like
to ask, what would be optimal procedure to perform reduction of vnodes in
existing 3.11.x cluster which was set up with default value 256. Cluster
has 2 DC with 5 nodes each and RF=3. There is one more
Thanks Erick!
I will check with the owners of this keyspace, hoping to find the culprit.
If they won't come up with anything, is there a way to read the key cache
file? (as I understand it's a binary file)
On another note, there's actually another keyspace I missed to point out on
which I found a
