It comes up from time to time.  Rob Coli spent years arguing that this
behavior was confusing ( ) , 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 <> 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 <> wrote:
> On Fri, Feb 23, 2018 at 10:12 AM, Oleksandr Shulgin <oleksandr.shulgin@
>> wrote:
>> On Fri, Feb 23, 2018 at 7:02 PM, Jeff Jirsa <> 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.

Reply via email to