From a7d8de14bbbe1722d1213f242e06949f2d3ecd2e Mon Sep 17 00:00:00 2001 From: Clinton Gormley Date: Tue, 11 Oct 2016 12:20:46 +0200 Subject: [PATCH] Removed the upgrade API docs Relates to #20675 --- docs/reference/indices.asciidoc | 3 - docs/reference/indices/upgrade.asciidoc | 123 ------------------------ 2 files changed, 126 deletions(-) delete mode 100644 docs/reference/indices/upgrade.asciidoc diff --git a/docs/reference/indices.asciidoc b/docs/reference/indices.asciidoc index 3c1eadfa07e4..afb5088d85e0 100644 --- a/docs/reference/indices.asciidoc +++ b/docs/reference/indices.asciidoc @@ -60,7 +60,6 @@ index settings, aliases, mappings, and index templates. * <> * <> * <> -* <> -- @@ -114,5 +113,3 @@ include::indices/refresh.asciidoc[] include::indices/forcemerge.asciidoc[] -include::indices/upgrade.asciidoc[] - diff --git a/docs/reference/indices/upgrade.asciidoc b/docs/reference/indices/upgrade.asciidoc deleted file mode 100644 index 1b8e99f21257..000000000000 --- a/docs/reference/indices/upgrade.asciidoc +++ /dev/null @@ -1,123 +0,0 @@ -[[indices-upgrade]] -== Upgrade - -The upgrade API allows to upgrade one or more indices to the latest Lucene -format through an API. The upgrade process converts any segments written with -older formats. - -[IMPORTANT] -=================================================== - -**The upgrade API in its current form will not help you to migrate indices -created in Elasticsearch 1.x to 5.x.** - -The upgrade API rewrites an index in the latest Lucene format, but it still -retains the original data structures that were used when the index was first -created. For instance: - -* Doc-values on numeric fields used to use BinaryDocValues, but now use dedicated NumericDocValues. -* The parent-child feature has been completely rewritten to use a new data structure. -* Geo-point fields now require doc values and the Lucene index where, previously, they relied on in-memory calculations. - -**Migrating 1.x indices to 5.x** - -The only way to prepare an index created in 1.x for use in 5.x is to **reindex -your data** in a cluster running Elasticsearch 2.3.x, which you can do with -the new <>. - -The steps to do this are as follows: - -1. Create a new index (e.g. `new_index`) with the correct settings and - mappings. These can be retrieved from the old index with the - <> API. - -2. Reindex from `old_index` to `new_index` with the - <>. - -3. Retrieve a list of any aliases associated with the `old_index` using the - <>. - -4. Delete the `old_index` using the <>. - -5. Add an alias called `old_index` to the `new_index` along with any aliases - returned in step 3, using the <>. - -In the future, we plan to change the upgrade API to perform a reindex-in- -place. In other words, it would reindex data from `old_index` to `.old_index` -then atomically delete `old_index` and rename `.old_index` to `old_index`. - -=================================================== - - -[float] -=== Start an upgrade - -[source,sh] --------------------------------------------------- -$ curl -XPOST 'http://localhost:9200/twitter/_upgrade' --------------------------------------------------- - -NOTE: Upgrading is an I/O intensive operation, and is limited to processing a -single shard per node at a time. It also is not allowed to run at the same -time as an optimize/force-merge. - -This call will block until the upgrade is complete. If the http connection -is lost, the request will continue in the background, and -any new requests will block until the previous upgrade is complete. - -[float] -[[upgrade-parameters]] -==== Request Parameters - -The `upgrade` API accepts the following request parameters: - -[horizontal] -`only_ancient_segments`:: If true, only very old segments (from a -previous Lucene major release) will be upgraded. While this will do -the minimal work to ensure the next major release of Elasticsearch can -read the segments, it's dangerous because it can leave other very old -segments in sub-optimal formats. Defaults to `false`. - -[float] -=== Check upgrade status - -Use a `GET` request to monitor how much of an index is upgraded. This -can also be used prior to starting an upgrade to identify which -indices you want to upgrade at the same time. - -The `ancient` byte values that are returned indicate total bytes of -segments whose version is extremely old (Lucene major version is -different from the current version), showing how much upgrading is -necessary when you run with `only_ancient_segments=true`. - -[source,sh] --------------------------------------------------- -curl 'http://localhost:9200/twitter/_upgrade?pretty&human' --------------------------------------------------- - -[source,js] --------------------------------------------------- -{ - "size": "21gb", - "size_in_bytes": "21000000000", - "size_to_upgrade": "10gb", - "size_to_upgrade_in_bytes": "10000000000" - "size_to_upgrade_ancient": "1gb", - "size_to_upgrade_ancient_in_bytes": "1000000000" - "indices": { - "twitter": { - "size": "21gb", - "size_in_bytes": "21000000000", - "size_to_upgrade": "10gb", - "size_to_upgrade_in_bytes": "10000000000" - "size_to_upgrade_ancient": "1gb", - "size_to_upgrade_ancient_in_bytes": "1000000000" - } - } -} --------------------------------------------------- - -The level of details in the upgrade status command can be controlled by -setting `level` parameter to `cluster`, `index` (default) or `shard` levels. -For example, you can run the upgrade status command with `level=shard` to -get detailed upgrade information of each individual shard.