You'd use different num_tokens only if you wanted an imbalance (e.g. New
hardware specs where you wanted to use fewer, larger machines).
--
Jeff Jirsa
> On Aug 19, 2017, at 6:04 PM, Subroto Barua
> wrote:
>
> Jeff,
>
> is it ok to have different values of
Jeff,
is it ok to have different values of num_tokens per node in a cluster? won't it
create cluster imbalance? or it better to initiate it on a separate DC?
Subroto
On Friday, August 18, 2017, 5:34:11 AM PDT, Durity, Sean R
wrote:
#yiv5432100827 #yiv5432100827 --
I am doing some on-the-job-learning on this newer feature of the 3.x line,
where the token generation algorithm will compensate for different size nodes
in a cluster. In fact, it is one of the main reasons I upgraded to 3.0.13,
because I have a number of original nodes in a cluster that are
I would preferably spin 2 JVMs inside the same hardware (if you double
everything) than having to deal with what Jeff stated.
Also certain operations are not really found of a large number of vnodes
(eg. repair). There was a lot of improvements in the 3.x release cycle, but
I do still tend to
If you really double the hardware in every way, it's PROBABLY reasonable to
double num_tokens. It won't be quite the same as doubling all-the-things,
because you still have a single JVM, and you'll still have to deal with GC
as you're now reading twice as much and generating twice as much garbage,
Are you saying if a node had double the hardware capacity in every way it
would be a bad idea to up num_tokens? I thought that was the whole idea of
that setting though?
On Thu, Aug 17, 2017 at 9:52 AM, Carlos Rolo wrote:
> No.
>
> If you would double all the hardware on that
No.
If you would double all the hardware on that node vs the others would still
be a bad idea.
Keep the cluster uniform vnodes wise.
Regards,
Carlos Juzarte Rolo
Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
Pythian - Love your data
rolo@pythian | Twitter: @cjrolo |