[ 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/dev@cassandra.apache.org/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