[prev in list] [next in list] [prev in thread] [next in thread]
List: cassandra-user
Subject: RE: Changing num_tokens and migrating to 4.0
From: "Durity, Sean R" <SEAN_R_DURITY () homedepot ! com>
Date: 2021-03-22 13:32:00
Message-ID: BL1P108MB0276C1F48129EDE8A6C2929FBC659 () BL1P108MB0276 ! NAMP108 ! PROD ! OUTLOOK ! COM
[Download RAW message or body]
[Attachment #2 (text/plain)]
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 <alexott@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 <lapo@lapo.it<mailto:lapo@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-unsubscribe@cassandra.apache.org<mailto:user-unsubscribe@cassandra.apache.org> \
For additional commands, e-mail: \
user-help@cassandra.apache.org<mailto:user-help@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.
[Attachment #3 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"> <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">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.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Sean Durity<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Alex Ott <alexott@gmail.com> <br>
<b>Sent:</b> Saturday, March 20, 2021 1:01 PM<br>
<b>To:</b> user <user@cassandra.apache.org><br>
<b>Subject:</b> [EXTERNAL] Re: Changing num_tokens and migrating to \
4.0<o:p></o:p></p> </div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p> </div>
<div>
<p class="MsoNormal">In Cassandra the disk size isn't the main "success" \
factor - it's a memory, CPU, disk type (SSD), etc.<o:p></o:p></p> </div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Sat, Mar 20, 2021 at 5:26 PM Lapo Luchini <<a \
href="mailto:lapo@lapo.it">lapo@lapo.it</a>> wrote:<o:p></o:p></p> </div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in \
6.0pt;margin-left:4.8pt;margin-right:0in"> <p class="MsoNormal" \
style="margin-bottom:12.0pt">Hi, thanks for suggestions!<br> I'll definitely migrate \
to 4.0 after all this is done, then.<br> <br>
Old prod DC I fear can't suffer losing a node right now (a few nodes <br>
have the disk 70% full), but I can maybe find a third node for the new <br>
DC right away.<br>
<br>
BTW the new nodes have got 3× the disk space, but are not so much <br>
different regarding CPU and RAM: does it make any sense giving them a <br>
bit more num_tokens (maybe 20-30 instead of 16) than the rest of the old <br>
DC hosts or "asymmetrical" clusters lead to problems?<br>
<br>
No real need to do that anyways, moving from 6 nodes to (eventually) 8 <br>
should be enough lessen the load on the disks, and before more space is <br>
needed I will probably have more nodes.<br>
<br>
Lapo<br>
<br>
On 2021-03-20 16:23, Alex Ott wrote:<br>
> I personally maybe would go following way (need to calculate how many <br>
> joins/decommissions will be at the end):<br>
> <br>
> * Decommission one node from prod DC<br>
> * Form new DC from two new machines and decommissioned one.<br>
> * Rebuild DC from existing one, make sure that repair finished, \
etc.<br> > * Switch traffic<br>
> * Remove old DC<br>
> * Add nodes from old DC one by one into new DC<br>
><br>
<br>
<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe, e-mail: <a href="mailto:user-unsubscribe@cassandra.apache.org" \
target="_blank"> user-unsubscribe@cassandra.apache.org</a><br>
For additional commands, e-mail: <a href="mailto:user-help@cassandra.apache.org" \
target="_blank"> user-help@cassandra.apache.org</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<br>
-- <o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">With best wishes, \
Alex Ott<br> <a \
href="https://urldefense.com/v3/__http:/alexott.net/__;!!M-nmYVHPHQ!Z88elRlG30NKZR9PseTGVv5t4zPzVdEmbaqJdUVKjfSbuqPg3fU1FnbH1o6KTwF8XWTzS8A$" \
target="_blank">http://alexott.net/ [alexott.net]</a><br>
Twitter: alexott_en (English), alexott (Russian)<o:p></o:p></p>
</div>
</div>
</div>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
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.<br> </font>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic