incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <>
Subject Re: Update: Cassandra Virtual Nodes
Date Sun, 24 Jun 2012 18:24:44 GMT
Is it fair to say that 3881 and 4121 are the key tickets, and the others
are mostly dealing with fallout from that?

On Wed, Jun 20, 2012 at 4:25 PM, Eric Evans <> wrote:
> So to followup on this, my take on the first discussion
> (
> was that there was some concern about how invasive this change would
> be.  This was then followed by discussion about the trade-offs between
> trying to push such a big change in all at once, versus an incremental
> approach, and the associated risks if for some reason we weren't able
> to follow through.
> The point we're at now is our first shot at trying to thread this
> needle.  As Sam says, it's at a point where it should be minimally
> useful, and should be backward compatible when run with 1 token per
> node (the default).  The patches I am referring to again are linked
> from:
> What we most need now is feedback, and consensus from the project.
> Consensus on the proposed changes, the implementation, the scope of
> the first iteration, and subsequent steps.
> Thanks,
> On Fri, Jun 1, 2012 at 11:50 AM, Sam Overton <> wrote:
>> Work on our proposed design is being tracked on JIRA:
>> We feel that our current implementation has sufficient functionality
>> to be useful in its own right, but is still a fairly self-contained
>> set of changes that can be incrementally improved - something which
>> was expressed as desirable in the last discussion. This is a good
>> point for a first round of review and to reach out to anyone
>> interested in testing or contributing.
>> == Obtaining the source ==
>> The easiest way to test these changes is to clone our github repo and
>> switch to the topic branch representing the top patch:
>>> git clone git://
>>> cd cassandra
>>> git checkout --track remotes/origin/p/4127/01_migration_path
>> Now just build with ant. To create a cluster with virtual-nodes
>> support just un-comment/edit the following parameter in
>> cassandra.yaml:
>>> num_tokens: 256
>> Make sure you have left initial_token blank. The node should
>> automatically assign itself this many tokens. You can view the token
>> assignment as usual with "nodetool ring" but this becomes fairly
>> useless with any large number of hosts/tokens, which is why we have
>> added "nodetool clusterinfo" which shows ring ownership without
>> cluttering the output with the token assignment.
>> If you want to test with a specific token assignment, initial_token
>> now supports a comma-separated list of tokens which will override the
>> num_tokens setting. This is just for convenience of testing - users
>> should no longer need to manually specify tokens as balancing is
>> automatic.
>> == Patches ==
>> The tickets which are in scope for this round of review are:
>> Each of these tickets has links to the corresponding patches. The
>> order they should be applied is just increasing numerical order of
>> ticket number.
>> These patches are based off another patch (currently pending review)
>> for CASSANDRA-3881, which was an existing issue blocking virtual
>> nodes.
>> Links to the individual patches can also be found all in one place on
>> the github wiki:
>> The current patches in the series are as follows:
>> * p/4121/01_support_multiple_tokens_per_host
>> support multiple tokens per host in TokenMetadata (CASSANDRA-4121)
>> * p/4122/01_bootstrap_decommission
>> support bootstrapping a node into the ring with multiple tokens and
>> minor changes for decommission (CASSANDRA-4122)
>> * p/4122/02_remove_tokens
>> minor changes to support remove-token with multiple tokens
>> * p/4125/01_admin_tools
>> nodetool support (addition of nodetool clusterinfo and changes to
>> nodetool ring) (CASSANDRA-4125)
>> * p/4127/01_migration_path
>> support for migration from 1-token to multi-token per node
>> If you wish to contribute or work with a clone from github then it
>> would be advisable to familiarise yourself with TopGit, the tool we
>> have been using for branch-based patch queue management. We've written
>> up a tutorial here:
>> == What's left? ==
>> We haven't included any patches for tickets CASSANDRA-4123 and
>> CASSANDRA-4124 which relate to the replication strategy and repair.
>> Currently replication and repair "just work" with the current patches
>> without any additional changes required.
>> CASSANDRA-4126 relates to testing. We're running virtual nodes builds
>> through our own test suites but we will also be writing new tests in
>> addition.
>> I look forward to your questions and comments!
> --
> Eric Evans
> Acunu | | @acunu

Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message