2020-07-23 12:42:33 -04:00
|
|
|
[discrete]
|
2019-10-02 04:27:17 -04:00
|
|
|
=== 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!>>
|
|
|
|
|
|
