From 41bc878738b9895a5b263ec5aa62c01202ba4119 Mon Sep 17 00:00:00 2001 From: David Turner Date: Mon, 30 Sep 2019 16:58:55 +0100 Subject: [PATCH] Clarify rolling-upgrade docs (#47279) Note to upgrade the master-eligible nodes last, and note that `cluster.initial_master_nodes` should not be set. --- docs/reference/upgrade/rolling_upgrade.asciidoc | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/reference/upgrade/rolling_upgrade.asciidoc b/docs/reference/upgrade/rolling_upgrade.asciidoc index bb50b60056f..23ed0f78a95 100644 --- a/docs/reference/upgrade/rolling_upgrade.asciidoc +++ b/docs/reference/upgrade/rolling_upgrade.asciidoc @@ -7,6 +7,12 @@ a time so upgrading does not interrupt service. Running multiple versions of not supported, as shards cannot be replicated from upgraded nodes to nodes running the older version. +It is best to upgrade the master-ineligible nodes in your cluster first and then +upgrade the master-eligible nodes. Once enough of the master-eligible nodes have +been upgraded they may form a cluster that nodes of older versions cannot join. +If you upgrade the master-eligible nodes last then all the other nodes will not +be running an older version and so they will be able to join the cluster. + Rolling upgrades are supported: * Between minor versions @@ -52,6 +58,11 @@ include::shut-down-node.asciidoc[] -- include::upgrade-node.asciidoc[] include::set-paths-tip.asciidoc[] + +[[rolling-upgrades-bootstrapping]] +NOTE: You should leave `cluster.initial_master_nodes` unset while performing a +rolling upgrade. Each upgraded node is joining an existing cluster so there is +no need for <>. -- . *Upgrade any plugins.*