cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Jirsa <jji...@gmail.com>
Subject Re: Adding a new node with the double of disk space
Date Sun, 20 Aug 2017 01:28:26 GMT
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 <sbarua116@yahoo.com.INVALID> wrote:
> 
> 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 <SEAN_R_DURITY@homedepot.com>
wrote:
> 
> 
> 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 about half the size of the newer nodes. With the same number of vnodes,
they can get overwhelmed with too much data and have to be rebuilt, etc.
> 
>  
> 
> So, I am cutting vnodes in half on those original nodes and rebuilding them. So far,
it is working as designed. The data size is about half on the smaller nodes.
> 
>  
> 
> With the more current advice being to use less vnodes, for the original question below,
I might consider adding the new node in at 256 vnodes and then rebuilding all the other nodes
at 128. Of course the cluster size and amount of data would be important factors, as well
as the future growth of the cluster and the expected size of any additional nodes.
> 
>  
> 
>  
> 
> Sean Durity
> 
>  
> 
> From: Jeff Jirsa [mailto:jjirsa@gmail.com] 
> Sent: Thursday, August 17, 2017 4:20 PM
> To: cassandra <user@cassandra.apache.org>
> Subject: Re: Adding a new node with the double of disk space
> 
>  
> 
> 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, but you can probably adjust the tuning of the heap to compensate.
> 
>  
> 
>  
> 
>  
> 
> On Thu, Aug 17, 2017 at 1:00 PM, Kevin O'Connor <kevin@reddit.com.invalid> wrote:
> 
> 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 <rolo@pythian.com> wrote:
> 
> 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 | Skype: cjr2k3 | Linkedin: linkedin.com/in/carlosjuzarterolo

> 
> Mobile: +351 918 918 100
> 
> www.pythian.com
> 
>  
> 
> On Thu, Aug 17, 2017 at 5:47 PM, Cogumelos Maravilha <cogumelosmaravilha@sapo.pt>
wrote:
> 
> Hi all,
> 
> I need to add a new node to my cluster but this time the new node will
> have the double of disk space comparing to the other nodes.
> 
> I'm using the default vnodes (num_tokens: 256). To fully use the disk
> space in the new node I just have to configure num_tokens: 512?
> 
> Thanks in advance.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: user-help@cassandra.apache.org
>  
> 
>  
> 
> --
> 
>  
> 
>  
> 
>  
> 
> 
> 
> The information in this Internet Email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this Email by anyone else is unauthorized.
If you are not the intended recipient, any disclosure, copying, distribution or any action
taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed
to our clients any opinions or advice contained in this Email are subject to the terms and
conditions expressed in any applicable governing The  Home Depot terms of business or client
engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy
and content of this attachment and for any damages or losses arising from any inaccuracies,
errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature,
which may be contained in this attachment and shall not be liable for direct, indirect, consequential
or special damages in connection with this e-mail message or its attachment.
> 

Mime
View raw message