107 lines
4.1 KiB
Plaintext
107 lines
4.1 KiB
Plaintext
[[reindex-upgrade]]
|
|
=== Reindex to upgrade
|
|
|
|
Elasticsearch is able to use indices created in the previous major version
|
|
only. For instance, Elasticsearch 6.x can use indices created in
|
|
Elasticsearch 5.x, but not those created in Elasticsearch 2.x or before.
|
|
|
|
NOTE: Elasticsearch 6.x nodes will fail to start in the presence of too old indices.
|
|
|
|
If you are running an Elasticsearch 5.x cluster which contains indices that
|
|
were created before 5.x, you will either need to delete those old indices or
|
|
to reindex them before upgrading to 6.x. See <<reindex-upgrade-inplace>>.
|
|
|
|
If you are running an Elasticsearch 2.x cluster or older, you have two options:
|
|
|
|
* First upgrade to Elasticsearch 5.x, reindex the old indices, then upgrade
|
|
to 6.x. See <<reindex-upgrade-inplace>>.
|
|
|
|
* Create a new 6.x cluster and use reindex-from-remote to import indices
|
|
directly from the 2.x cluster. See <<reindex-upgrade-remote>>.
|
|
|
|
.Time-based indices and retention periods
|
|
*******************************************
|
|
|
|
For many use cases with time-based indices, you will not need to worry about
|
|
carrying old 2.x indices with you to 6.x. Data in time-based indices usually
|
|
becomes less interesting as time passes. Old indices can be deleted once they
|
|
fall outside of your retention period.
|
|
|
|
Users in this position can continue to use 5.x until all old 2.x indices have
|
|
been deleted, then upgrade to 6.x directly.
|
|
|
|
*******************************************
|
|
|
|
|
|
[[reindex-upgrade-inplace]]
|
|
==== Reindex in place
|
|
|
|
If you are running a 5.x cluster which contains indices created in
|
|
Elasticsearch 2.x, you will need to reindex (or delete) those indices before
|
|
upgrading to Elasticsearch 6.x.
|
|
|
|
The reindex process works as follows:
|
|
|
|
* Create a new index, copying the mappings and settings from the old index.
|
|
Set the `refresh_interval` to `-1` and the `number_of_replicas` to `0` for
|
|
efficient reindexing.
|
|
|
|
* Reindex all documents from the old index to the new index using the
|
|
<<docs-reindex,reindex API>>.
|
|
|
|
* Reset the `refresh_interval` and `number_of_replicas` to the values
|
|
used in the old index, and wait for the index to become green.
|
|
|
|
* In a single <<indices-aliases,update aliases>> request:
|
|
|
|
* Delete the old index.
|
|
* Add an alias with the old index name to the new index.
|
|
* Add any aliases that existed on the old index to the new index.
|
|
|
|
At the end of this process, you will have a new 5.x index which can be used
|
|
by an Elasticsearch 6.x cluster.
|
|
|
|
[[reindex-upgrade-remote]]
|
|
==== Upgrading with reindex-from-remote
|
|
|
|
If you are running a 1.x or 2.x cluster and would like to migrate directly to 6.x
|
|
without first migrating to 5.x, you can do so using
|
|
<<reindex-from-remote,reindex-from-remote>>.
|
|
|
|
[WARNING]
|
|
=============================================
|
|
|
|
Elasticsearch includes backwards compatibility code that allows indices from
|
|
the previous major version to be upgraded to the current major version. By
|
|
moving directly from Elasticsearch 2.x or before to 6.x, you will have to solve any
|
|
backwards compatibility issues yourself.
|
|
|
|
=============================================
|
|
|
|
You will need to set up a 6.x cluster alongside your existing old cluster.
|
|
The 6.x cluster needs to have access to the REST API of the old cluster.
|
|
|
|
For each old index that you want to transfer to the 6.x cluster, you will need
|
|
to:
|
|
|
|
* Create a new index in 6.x with the appropriate mappings and settings. Set
|
|
the `refresh_interval` to `-1` and set `number_of_replicas` to `0` for
|
|
faster reindexing.
|
|
|
|
* Use <<reindex-from-remote,reindex-from-remote>> to pull documents from the
|
|
old index into the new 6.x index.
|
|
|
|
* If you run the reindex job in the background (with `wait_for_completion` set
|
|
to `false`), the reindex request will return a `task_id` which can be used to
|
|
monitor progress of the reindex job in the <<tasks,task API>>:
|
|
`GET _tasks/TASK_ID`.
|
|
|
|
* Once reindex has completed, set the `refresh_interval` and
|
|
`number_of_replicas` to the desired values (the defaults are `30s` and `1`
|
|
respectively).
|
|
|
|
* Once the new index has finished replication, you can delete the old index.
|
|
|
|
The 6.x cluster can start out small, and you can gradually move nodes from the
|
|
old cluster to the 6.x cluster as you migrate indices across.
|