mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-03-25 01:19:02 +00:00
Clarify that you cannot abort an upgrade (#47342)
We do mention that rolling back an upgrade requires a restore from a snapshot, but it's hidden at the bottom of the "preparing to upgrade" instructions on a different page from the actual upgrade instructions. This commit duplicates the preparatory instructions onto the pages containing the actual upgrade instructions and rewords the point about rollbacks a bit.
This commit is contained in:
parent
98c1c2f650
commit
7739938930
@ -68,21 +68,6 @@ To upgrade directly to {version} from 6.7 or earlier, you must shut down the
|
||||
cluster, install {version}, and restart. For more information, see
|
||||
<<restart-upgrade, Full cluster restart upgrade>>.
|
||||
|
||||
[float]
|
||||
== Preparing to upgrade
|
||||
|
||||
Before upgrading {es}:
|
||||
|
||||
. Check the <<deprecation-logging, deprecation log>> to see if you are using
|
||||
any deprecated features and update your code accordingly. By default,
|
||||
deprecation warnings are logged when the log level is set to `WARN`.
|
||||
. Review the <<breaking-changes,breaking changes>> and make any necessary changes
|
||||
to your code and configuration for {version}.
|
||||
. If you use custom plugins, make sure compatible versions are available.
|
||||
. Test upgrades in a dev environment before upgrading your production cluster.
|
||||
. <<modules-snapshots,Back up your data!>> You must have a snapshot of your
|
||||
data to roll back to an earlier version.
|
||||
|
||||
--
|
||||
|
||||
include::upgrade/rolling_upgrade.asciidoc[]
|
||||
|
@ -9,7 +9,12 @@ NOTE: If you are running a version prior to 6.0,
|
||||
and reindex your old indices or bring up a new {version} cluster and
|
||||
<<reindex-upgrade-remote, reindex from remote>>.
|
||||
|
||||
To perform a full cluster restart upgrade to {version}:
|
||||
include::preparing_to_upgrade.asciidoc[]
|
||||
|
||||
[float]
|
||||
=== Upgrading your cluster
|
||||
|
||||
To perform a full cluster restart upgrade to {version}:
|
||||
|
||||
. *Disable shard allocation.*
|
||||
+
|
||||
@ -52,6 +57,11 @@ include::upgrade-node.asciidoc[]
|
||||
include::set-paths-tip.asciidoc[]
|
||||
--
|
||||
|
||||
If upgrading from a 6.x cluster, you must also
|
||||
<<modules-discovery-bootstrap-cluster,configure cluster bootstrapping>> by
|
||||
setting the <<initial_master_nodes,`cluster.initial_master_nodes` setting>> on
|
||||
the master-eligible nodes.
|
||||
|
||||
. *Upgrade any plugins.*
|
||||
+
|
||||
Use the `elasticsearch-plugin` script to install the upgraded version of each
|
||||
@ -70,10 +80,6 @@ If you have dedicated master nodes, start them first and wait for them to
|
||||
form a cluster and elect a master before proceeding with your data nodes.
|
||||
You can check progress by looking at the logs.
|
||||
|
||||
If upgrading from a 6.x cluster, you must
|
||||
<<modules-discovery-bootstrap-cluster,configure cluster bootstrapping>> by
|
||||
setting the `cluster.initial_master_nodes` setting.
|
||||
|
||||
As soon as enough master-eligible nodes have discovered each other, they form a
|
||||
cluster and elect a master. At that point, you can use
|
||||
<<cat-health,`_cat/health`>> and <<cat-nodes,`_cat/nodes`>> to monitor nodes
|
||||
|
28
docs/reference/upgrade/preparing_to_upgrade.asciidoc
Normal file
28
docs/reference/upgrade/preparing_to_upgrade.asciidoc
Normal file
@ -0,0 +1,28 @@
|
||||
[float]
|
||||
=== Preparing to upgrade
|
||||
|
||||
It is important to prepare carefully before starting an upgrade. Once you have
|
||||
started to upgrade your cluster to version {version} you must complete the
|
||||
upgrade. As soon as the cluster contains nodes of version {version} it may make
|
||||
changes to its internal state that cannot be reverted. If you cannot complete
|
||||
the upgrade then you should discard the partially-upgraded cluster, deploy an
|
||||
empty cluster of the version before the upgrade, and restore its contents from
|
||||
a snapshot.
|
||||
|
||||
Before you start to upgrade your cluster to version {version} you should do the
|
||||
following.
|
||||
|
||||
. Check the <<deprecation-logging, deprecation log>> to see if you are using any
|
||||
deprecated features and update your code accordingly.
|
||||
|
||||
. Review the <<breaking-changes,breaking changes>> and make any necessary
|
||||
changes to your code and configuration for version {version}.
|
||||
|
||||
. If you use any plugins, make sure there is a version of each plugin that is
|
||||
compatible with {es} version {version}.
|
||||
|
||||
. Test the upgrade in an isolated environment before upgrading your production
|
||||
cluster.
|
||||
|
||||
. <<modules-snapshots,Back up your data by taking a snapshot!>>
|
||||
|
@ -22,7 +22,12 @@ Rolling upgrades are supported:
|
||||
Upgrading directly to {version} from 6.7 or earlier requires a
|
||||
<<restart-upgrade, full cluster restart>>.
|
||||
|
||||
To perform a rolling upgrade from 6.8 to {version}:
|
||||
include::preparing_to_upgrade.asciidoc[]
|
||||
|
||||
[float]
|
||||
=== Upgrading your cluster
|
||||
|
||||
To perform a rolling upgrade to {version}:
|
||||
|
||||
. *Disable shard allocation*.
|
||||
+
|
||||
|
Loading…
x
Reference in New Issue
Block a user