Discovery.seed_hosts and cluster.initial_master_nodes

Elastic Stack Elasticsearch
1

I'm struggling to understand the discovery settings now that
discovery.zen.minimum_master_nodes has gone away.

(where current is 8.7) says that discovery.seed_hosts

Provides a list of the addresses of the master-eligible nodes in the
cluster.

But then there's also cluster.initial_master_nodes

Sets the initial set of master-eligible nodes in a brand-new cluster.

So one has to specify the list of master eligible nodes twice. Which
seems odd.

says of cluster.initial_master_nodes

Remove this setting once the cluster has formed.

provides a much stronger warning with the words about removing the
setting presented next to an image of a warning sign and the word
IMPORTANT. Nothing is said about why it's IMPORTANT. I've found a post
on this forum which says there is potential for data loss, in "rare
circumstances".

It used to be that configuration for nodes in a new cluster could be deployed then simply left alone. Now people are expected to deploy one set of configuration and remember that once the cluster is up and running, they should deploy different configuration. This seems clunky, unintuitive, and setting people up to fail. It is inevitable that some will forget to remove the setting.

Please could someone explain:

Why do discovery.seed_hosts and cluster.initial_master_nodes both exist?

What problems may result from a failure to remove cluster.initial_master_nodes ?

2

The former pertains to discovery: it allows you to specify the addresses of the master nodes. This is needed whenever a node starts up, or a new master is elected. The latter pertains to cluster bootstrapping and requires the identities (i.e. the names) of the master nodes. It only happens once in the lifetime of a cluster. They're very different things. The older minimum_master_nodes mechanism was removed a very long time ago since it was fundamentally unsafe and led to data loss.

This is covered by the docs linked from the ones you linked:

If you leave cluster.initial_master_nodes in place once the cluster has formed then there is a risk that a future misconfiguration may result in bootstrapping a new cluster alongside your existing cluster. It may not be possible to recover from this situation without losing data.

3

... moreover, those ancient versions also required you to set discovery.zen.ping.unicast.hosts, which did exactly what discovery.seed_hosts does today. It's just a shorter name for the same setting.

4

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.