cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Bailey (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4658) NTS/RackAwareness doesn't work with vnodes
Date Wed, 12 Sep 2012 17:40:09 GMT


Nick Bailey commented on CASSANDRA-4658:

We could potentially say that rack awareness and vnodes are incompatible. Which will essentially
mean that cassandra can't guarantee that losing a single rack won't bring down an entire replica
set. That makes the problem slightly easier, but still requires some sort of clear upgrade
path for people on NTS with racks. Changing the replication strategy or changing the snitch
to report different racks won't cause data to be streamed to any new owners. So we would need
to come up with a mechanism for updating without data loss.
> NTS/RackAwareness doesn't work with vnodes
> ------------------------------------------
>                 Key: CASSANDRA-4658
>                 URL:
>             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:

View raw message