Also agree it should be lowered, but definitely not to 1, and probably something closer to 32 than 4.
-- Jeff Jirsa > On Sep 21, 2018, at 8:24 PM, Jeremy Hanna <jeremy.hanna1...@gmail.com> wrote: > > I agree that it should be lowered. What I’ve seen debated a bit in the past > is the number but I don’t think anyone thinks that it should remain 256. > >> On Sep 21, 2018, at 7:05 PM, Jonathan Haddad <j...@jonhaddad.com> wrote: >> >> One thing that's really, really bothered me for a while is how we default >> to 256 tokens still. There's no experienced operator that leaves it as is >> at this point, meaning the only people using 256 are the poor folks that >> just got started using C*. I've worked with over a hundred clusters in the >> last couple years, and I think I only worked with one that had lowered it >> to something else. >> >> I think it's time we changed the default to 4 (or 8, up for debate). >> >> To improve the behavior, we need to change a couple other things. The >> allocate_tokens_for_keyspace setting is... odd. It requires you have a >> keyspace already created, which doesn't help on new clusters. What I'd >> like to do is add a new setting, allocate_tokens_for_rf, and set it to 3 by >> default. >> >> To handle clusters that are already using 256 tokens, we could prevent the >> new node from joining unless a -D flag is set to explicitly allow >> imbalanced tokens. >> >> We've agreed to a trunk freeze, but I feel like this is important enough >> (and pretty trivial) to do now. I'd also personally characterize this as a >> bug fix since 256 is horribly broken when the cluster gets to any >> reasonable size, but maybe I'm alone there. >> >> I honestly can't think of a use case where random tokens is a good choice >> anymore, so I'd be fine / ecstatic with removing it completely and >> requiring either allocate_tokens_for_keyspace (for existing clusters) >> or allocate_tokens_for_rf >> to be set. >> >> Thoughts? Objections? >> -- >> Jon Haddad >> http://www.rustyrazorblade.com >> twitter: rustyrazorblade > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
