It comes up from time to time. Rob Coli spent years arguing that this behavior was confusing ( https://issues.apache.org/jira/browse/CASSANDRA-5836 ) , especially in the "I'm replacing a failed seed" sense. It also comes up when you're adding the first few hosts to a new DC (where they're new, but they're definitely going to be the seeds for the new DC).
On Fri, Feb 23, 2018 at 10:22 AM, Jon Haddad <j...@jonhaddad.com> wrote: > In my opinion and experience, this isn’t a real problem, since you define > a list of seeds as the first few nodes you add to a cluster. When would > you add a node to an existing cluster and mark itself as a seed? It’s > neither practical or something you’d do by accident. > > On Feb 23, 2018, at 10:17 AM, Jeff Jirsa <jji...@gmail.com> wrote: > > > On Fri, Feb 23, 2018 at 10:12 AM, Oleksandr Shulgin <oleksandr.shulgin@ > zalando.de> wrote: > >> On Fri, Feb 23, 2018 at 7:02 PM, Jeff Jirsa <jji...@gmail.com> wrote: >>> >>> Yes, seeds don't bootstrap. But why? I don't think I ever seen a >>>> comprehensive explanation of this. >>>> >>>> The meaning of seed in the most common sense is "connect to this host, >>> and use it as the starting point for adding this node to the cluster". >>> >>> If you specify that a joining node is the seed, the implication is that >>> it's already a member of the cluster (or, alternatively, authoritative on >>> the cluster's state). Given that implication, why would it make sense to >>> then proceed to bootstrap? By setting it as a seed, you've told it that it >>> already knows what the cluster is. >>> >> >> Well, there is certain logic in that. However, bootstrap is about >> streaming in the data, isn't it? And being seed is about knowing the >> topology, i.e. which nodes exist in the cluster. There is actually 0 >> overlap of these two concerns, so I don't really see why a seed node >> shouldn't be able to bootstrap. Would it break anything if it could, e.g. >> if you're explicit about it and request auto_boostrap=true? >> >> > I dont *think* it would break anything, but the more obvious answer is > just not to list the node as a seed if it needs to bootstrap. > > This comes up a lot, and it's certainly one of those rough operator edges > that we can do better with. There's no strict requirement to have all of > the seeds exactly the same in a cluster, so if you need to bootstrap a new > seed, just join it with it not a seed, then bounce it to make it think it's > a seed after it's joined. > > The easier answer is probably "give people a way to change seeds after > they're running", and it sorta exists, but it's hard to invoke > intentionally. We should just make that easier, and the rough edges will > get a little less rough. > > >
