[
https://issues.apache.org/jira/browse/CASSANDRA-4119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-4119.
---------------------------------------
Resolution: Fixed
Fix Version/s: 1.2.0
> Support multiple non-consecutive tokens per host (virtual nodes)
> ----------------------------------------------------------------
>
> Key: CASSANDRA-4119
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4119
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Sam Overton
> Assignee: Sam Overton
> Labels: virtualnodes, vnodes
> Fix For: 1.2.0
>
>
> This is the parent ticket for the virtual nodes implementation which was
> proposed here:
> http://www.mail-archive.com/[email protected]/msg03837.html and
> discussed in the subsequent thread.
> The goals of this ticket are:
> * reduced operations complexity for scaling up/down
> * reduced rebuild time in event of failure
> * evenly distributed load impact in the event of failure
> * evenly distributed impact of streaming operations
> * more viable support for heterogeneity of hardware
> The intention is that this can be done in a way which is
> * fully backwards-compatible
> * optionally enabled
> The latter of these can be trivially achieved by setting the number of tokens
> per host to 1, to reproduce the existing behaviour.
> Implementation detail can be added and discussed in the sub-tickets, but here
> is an overview of the proposed changes:
> * TokenMetadata will allow multiple tokens per host
> * Hosts will be referred to by a UUID instead of token (e.g. in Gossip, when
> storing hints, etc.)
> * A bootstrapping node can get multiple tokens from initial_token (comma
> separated) or by random allocation
> * NetworkTopologyStrategy will be extended to be aware of virtual nodes so
> that replicas are not placed on the same host (similar to racks now)
> * Repairs will be staggered similar to CASSANDRA-3721
> * Nodetool operations will be virtual-node aware, while maintaining backwards
> compatibility (ie. existing scripts won't have to change)
> * Upgrade will be a standard rolling upgrade, with optional rolling migration
> to full vnode support
--
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
