[
https://issues.apache.org/jira/browse/CASSANDRA-4119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13397967#comment-13397967
]
Eric Evans commented on CASSANDRA-4119:
---------------------------------------
bq. Default; 64
Was it 64, or 256 (the default is 256)?
> 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
>
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
