[
https://issues.apache.org/jira/browse/CASSANDRA-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455080#comment-13455080
]
Vijay commented on CASSANDRA-4658:
----------------------------------
{quote}
That's impossible to do in a new cluster, though.
{quote}
What i was thinking was: When the First node is added to Rack1 then we dont
know about RAC2 and 3, so we use a purely go with random tokens.... When RAC2
node comes online it should compare and take spots which will intersecting the
other RAC1. When RAC3 is added then they have to intersect RAC1 and 2. I am not
saying this is perfect solution we can at-least reduce the probability of the
ranges being in the same RAC. (We can complicate the logic as much as we want
to get a even proportion during bootstrap phase... :) ).
> NTS/RackAwareness doesn't work with vnodes
> ------------------------------------------
>
> Key: CASSANDRA-4658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4658
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 1.2.0 beta 1
> Reporter: Nick Bailey
> Fix For: 1.2.0
>
>
> It doesn't look like the current vnode placement strategy will work with
> people using NTS and multiple racks.
> For reasons also described on CASSANDRA-3810, using racks and NTS requires
> tokens to alternate racks around the ring in order to get an even
> distribution of data. The current solution for upgrading/placing vnodes won't
> take this into account and will likely generate some hotspots around the
> ring.
> Not sure what the best solution is. The two immediately obvious approaches
> appear to be quite complicated at first.
> * Fixing NTS to remove the requirement for rack ordering
> ** No idea how this would be accomplished
> ** Presents challenges for people upgrading. Would need to deprecate NTS for
> a new strategy that replaces it, then have a clear upgrade path to that
> strategy which would need to be in a pre 1.2 release.
> * Changing vnode placement strategy
> ** Ordering vnodes would require quite a bit of additional logic. Adding a
> new node or rack would also need to maintain ordering which could cause
> enough data movement to remove any benefits vnodes have already.
> ** We could potentially adjust vnode token placement to offset any imbalances
> caused by NTS but this would require a fairly intelligent mechanism for
> determining vnode placement.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
