I have a cluster (almost 200 nodes) with a variety of disk sizes and use different numbers of tokens so that the machines can use the disk they have. It is a very handy feature! While I agree that a node with larger disk may handle more requests, that may not be enough to impact CPU or memory. I rarely see Cassandra CPU-bound for my use cases. These are primarily write use cases with a low number of clients with far fewer reads. There is just a lot of data to keep.
Sean Durity From: Alex Ott <alex...@gmail.com> Sent: Saturday, March 20, 2021 1:01 PM To: user <user@cassandra.apache.org> Subject: [EXTERNAL] Re: Changing num_tokens and migrating to 4.0 if the nodes are almost the same, except the disk space, then giving them more may make siltation worse - they will get more requests than other nodes, and won't have resources to process them. In Cassandra the disk size isn't the main "success" factor - it's a memory, CPU, disk type (SSD), etc. On Sat, Mar 20, 2021 at 5:26 PM Lapo Luchini <l...@lapo.it<mailto:l...@lapo.it>> wrote: Hi, thanks for suggestions! I'll definitely migrate to 4.0 after all this is done, then. Old prod DC I fear can't suffer losing a node right now (a few nodes have the disk 70% full), but I can maybe find a third node for the new DC right away. BTW the new nodes have got 3× the disk space, but are not so much different regarding CPU and RAM: does it make any sense giving them a bit more num_tokens (maybe 20-30 instead of 16) than the rest of the old DC hosts or "asymmetrical" clusters lead to problems? No real need to do that anyways, moving from 6 nodes to (eventually) 8 should be enough lessen the load on the disks, and before more space is needed I will probably have more nodes. Lapo On 2021-03-20 16:23, Alex Ott wrote: > I personally maybe would go following way (need to calculate how many > joins/decommissions will be at the end): > > * Decommission one node from prod DC > * Form new DC from two new machines and decommissioned one. > * Rebuild DC from existing one, make sure that repair finished, etc. > * Switch traffic > * Remove old DC > * Add nodes from old DC one by one into new DC > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org<mailto:user-unsubscr...@cassandra.apache.org> For additional commands, e-mail: user-h...@cassandra.apache.org<mailto:user-h...@cassandra.apache.org> -- With best wishes, Alex Ott http://alexott.net/ [alexott.net]<https://urldefense.com/v3/__http:/alexott.net/__;!!M-nmYVHPHQ!Z88elRlG30NKZR9PseTGVv5t4zPzVdEmbaqJdUVKjfSbuqPg3fU1FnbH1o6KTwF8XWTzS8A$> Twitter: alexott_en (English), alexott (Russian) ________________________________ 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.
