123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140 |
- [[reindex-upgrade]]
- == Reindex before upgrading
- {es} can read indices created in the previous major version. If you
- have indices created in 5.x or before, you must reindex or delete them
- before upgrading to {version}. {es} nodes will fail to start if
- incompatible indices are present. Snapshots of 5.x or earlier indices cannot be
- restored to a 7.x cluster even if they were created by a 6.x cluster.
- You have two options for reindexing old indices:
- * <<reindex-upgrade-inplace, Reindex in place>> on your 6.x cluster before upgrading.
- * Create a new {version} cluster and <<reindex-upgrade-remote, Reindex from remote>>.
- This enables you to reindex indices that reside on clusters running any version of {es}.
- .Upgrading time-based indices
- *******************************************
- If you use time-based indices, you likely won't need to carry
- pre-6.x indices forward to {version}. Data in time-based indices
- generally becomes less useful as time passes and are
- deleted as they age past your retention period.
- Unless you have an unusually long retention period, you can just
- wait to upgrade to 6.x until all of your pre-6.x indices have
- been deleted.
- *******************************************
- [[reindex-upgrade-inplace]]
- === Reindex in place
- You can use the Upgrade Assistant in {kib} 6.7 to automatically reindex 5.x
- indices you need to carry forward to {version}.
- To manually reindex your old indices in place:
- . Create an index with 7.x compatible mappings.
- . Set the `refresh_interval` to `-1` and the `number_of_replicas` to `0` for
- efficient reindexing.
- . Use the <<docs-reindex,`reindex` API>> to copy documents from the
- 5.x index into the new index. You can use a script to perform any necessary
- modifications to the document data and metadata during reindexing.
- . Reset the `refresh_interval` and `number_of_replicas` to the values
- used in the old index.
- . Wait for the index status to change to `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.
- [[reindex-upgrade-remote]]
- === Reindex from a remote cluster
- You can use <<reindex-from-remote,reindex from remote>> to migrate indices from
- your old cluster to a new {version} cluster. This enables you move to {version}
- from a pre-6.7 cluster without interrupting service.
- [WARNING]
- =============================================
- {es} provides backwards compatibility support that enables
- indices from the previous major version to be upgraded to the
- current major version. Skipping a major version means that you must
- resolve any backward compatibility issues yourself.
- =============================================
- To migrate your indices:
- . Set up a new {version} cluster and add the existing cluster to the
- `reindex.remote.whitelist` in `elasticsearch.yml`.
- +
- --
- [source,yaml]
- --------------------------------------------------
- reindex.remote.whitelist: oldhost:9200
- --------------------------------------------------
- [NOTE]
- =============================================
- The new cluster doesn't have to start fully-scaled out. As you migrate
- indices and shift the load to the new cluster, you can add nodes to the new
- cluster and remove nodes from the old one.
- =============================================
- --
- . For each index that you need to migrate to the new cluster:
- .. Create an index the appropriate mappings and settings. Set the
- `refresh_interval` to `-1` and set `number_of_replicas` to `0` for
- faster reindexing.
- .. Use the <<docs-reindex,`reindex` API>> to pull documents from the
- remote index into the new {version} index:
- +
- --
- [source,js]
- --------------------------------------------------
- POST _reindex
- {
- "source": {
- "remote": {
- "host": "http://oldhost:9200",
- "username": "user",
- "password": "pass"
- },
- "index": "source",
- "query": {
- "match": {
- "test": "data"
- }
- }
- },
- "dest": {
- "index": "dest"
- }
- }
- --------------------------------------------------
- // CONSOLE
- // TEST[setup:host]
- // TEST[s/^/PUT source\n/]
- // TEST[s/oldhost:9200",/\${host}"/]
- // TEST[s/"username": "user",//]
- // TEST[s/"password": "pass"//]
- If you run the reindex job in the background by setting `wait_for_completion`
- to `false`, the reindex request returns a `task_id` you can use to
- monitor progress of the reindex job with the <<tasks,task API>>:
- `GET _tasks/TASK_ID`.
- --
- .. When the reindex job completes, set the `refresh_interval` and
- `number_of_replicas` to the desired values (the default settings are
- `30s` and `1`).
- .. Once reindexing is complete and the status of the new index is `green`,
- you can delete the old index.
|