Mention full-cluster restart in initial_master_node docs (#112986)

Apparently some users consider "node is restarting" not to apply to a
full-cluster restart. This commit further clarifies that you must not
set `cluster.initial_master_nodes` in a full cluster restart.

Author: DaveCTurner

docs/reference/modules/discovery/bootstrapping.asciidoc

@@ -5,7 +5,7 @@ Starting an Elasticsearch cluster for the very first time requires the initial
 set of <<master-node,master-eligible nodes>> to be explicitly defined on one or
 more of the master-eligible nodes in the cluster. This is known as _cluster
 bootstrapping_. This is only required the first time a cluster starts up.
-Freshly-started nodes that are joining a running cluster obtain this 
+Freshly-started nodes that are joining a running cluster obtain this
 information from the cluster's elected master.
 
 The initial set of master-eligible nodes is defined in the
@@ -27,17 +27,20 @@ node:
   if it is not possible to use the `node.name` of the node and there are
   multiple nodes sharing a single IP address.
 
+Do not set `cluster.initial_master_nodes` on master-ineligible nodes.
+
 [IMPORTANT]
 ====
 After the cluster has formed, remove the `cluster.initial_master_nodes` setting
-from each node's configuration. It should not be set for master-ineligible
-nodes, master-eligible nodes joining an existing cluster, or nodes which are
-restarting.
-
-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.
+from each node's configuration and never set it again for this cluster. Do not
+configure this setting on nodes joining an existing cluster. Do not configure
+this setting on nodes which are restarting. Do not configure this setting when
+performing a full-cluster restart.
+
+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.
 ====
 
 The simplest way to create a new cluster is for you to select one of your

docs/reference/modules/discovery/discovery-settings.asciidoc

@@ -46,8 +46,11 @@ setting, see <<single-node-discovery>>.
 Sets the initial set of master-eligible nodes in a brand-new cluster. By
 default this list is empty, meaning that this node expects to join a cluster
 that has already been bootstrapped. Remove this setting once the cluster has
-formed. Do not use this setting when restarting nodes or when adding new nodes
-to an existing cluster. See <<initial_master_nodes>>.
+formed, and never set it again for this cluster. Do not configure this setting
+on master-ineligible nodes. Do not configure this setting on nodes joining an
+existing cluster. Do not configure this setting on nodes which are restarting.
+Do not configure this setting when performing a full-cluster restart. See
+<<initial_master_nodes>>.
 
 [discrete]
 ==== Expert settings

docs/reference/setup/bootstrap-checks.asciidoc

@@ -245,10 +245,9 @@ properties:
 - `discovery.seed_providers`
 - `cluster.initial_master_nodes`
 
-Note that you should remove `cluster.initial_master_nodes` from the
-configuration after the cluster has started for the first time. Do not use this
-setting when restarting nodes or when adding new nodes to an existing cluster.
-Instead, configure `discovery.seed_hosts` or `discovery.seed_providers`. If you
-do not need any discovery configuration, for instance if running a single-node
-cluster, set `discovery.seed_hosts: []` to disable discovery and satisfy this
-bootstrap check.
+Note that you must <<initial_master_nodes,remove `cluster.initial_master_nodes`
+from the configuration of every node>> after the cluster has started for the
+first time. Instead, configure `discovery.seed_hosts` or
+`discovery.seed_providers`. If you do not need any discovery configuration, for
+instance if running a single-node cluster, set `discovery.seed_hosts: []` to
+disable discovery and satisfy this bootstrap check.

docs/reference/setup/important-settings/discovery-settings.asciidoc

@@ -53,16 +53,18 @@ first election. In <<dev-vs-prod-mode,development mode>>, with no discovery
 settings configured, this step is performed automatically by the nodes
 themselves.
 
-Because auto-bootstrapping is <<modules-discovery-quorums,inherently
-unsafe>>, when starting a new cluster in production
-mode, you must explicitly list the master-eligible nodes whose votes should be
-counted in the very first election. You set this list using the
-`cluster.initial_master_nodes` setting.
+Because auto-bootstrapping is <<modules-discovery-quorums,inherently unsafe>>,
+when starting a new cluster in production mode, you must explicitly list the
+master-eligible nodes whose votes should be counted in the very first election.
+You set this list using the `cluster.initial_master_nodes` setting on every
+master-eligible node. Do not configure this setting on master-ineligible nodes.
 
 IMPORTANT: After the cluster forms successfully for the first time, remove the
-`cluster.initial_master_nodes` setting from each node's configuration. Do not
-use this setting when restarting a cluster or adding a new node to an existing
-cluster.
+`cluster.initial_master_nodes` setting from each node's configuration and never
+set it again for this cluster. Do not configure this setting on nodes joining
+an existing cluster. Do not configure this setting on nodes which are
+restarting. Do not configure this setting when performing a full-cluster
+restart. See <<modules-discovery-bootstrap-cluster>>.
 
 [source,yaml]
 --------------------------------------------------