|
@@ -0,0 +1,92 @@
|
|
|
+[[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>>.
|
|
|
+
|
|
|
+[[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.
|