29 lines
1.1 KiB
Plaintext
29 lines
1.1 KiB
Plaintext
|
[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!>>
|
||
|
|
|