cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Evans (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4119) Support multiple non-consecutive tokens per host (virtual nodes)
Date Wed, 20 Jun 2012 22:49:43 GMT

    [ 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/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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message