On Fri, Aug 24, 2012 at 3:39 PM, Eric Evans <eev...@acunu.com> wrote: > On Fri, Aug 24, 2012 at 11:27 AM, Jonathan Ellis <jbel...@gmail.com> wrote: >> On Fri, Aug 24, 2012 at 11:23 AM, Eric Evans <eev...@acunu.com> wrote: >>> Actually, now that I think about it, I'd probably drop the entire >>> notion of a "coordinator", and write the respective entiries into a >>> column family in the system keyspaces. Each system could then work >>> through their respective queue of relocations at their own pace. >> >> Sounds reasonable. > > OK, then unless someone steps forward with a better idea, I'll proceed > with this approach.
I've updated the ticket[1] with a link to a patch[2] that implements what I was thinking here. Each node implements a scheduler that periodically looks in a system table for token ranges that should be relocated to it. As a safety measure, it will skip new transfers if the actual number of tokens exceeds num_tokens by 10% or more (giving slower nodes a chance to catch up, if needed). The periodic scheduler can be enabled and disabled using JMX. What remains is to create the administrative tool, something to calculate the token moves and populate the tables with the respective entries. Any thoughts on this? Should this be something baked into nodetool, or a separate utility? Can we add the entries directly, or should this be done via JMX? Also, do we have an exact date for the freeze yet? I assume I have at least until Sylvain returns from holiday. :) Thoughts, comments, ideas? [1]: https://issues.apache.org/jira/browse/CASSANDRA-4443 [2]: https://github.com/acunu/cassandra/compare/top-bases/p/4443/050_process_queued_xfers...p/4443/050_process_queued_xfers.diff -- Eric Evans Acunu | http://www.acunu.com | @acunu
