upgrade.asciidoc 2.7 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879
  1. [[indices-upgrade]]
  2. == Upgrade
  3. The upgrade API allows to upgrade one or more indices to the latest format
  4. through an API. The upgrade process converts any segments written
  5. with previous formats.
  6. [float]
  7. === Start an upgrade
  8. [source,sh]
  9. --------------------------------------------------
  10. $ curl -XPOST 'http://localhost:9200/twitter/_upgrade'
  11. --------------------------------------------------
  12. NOTE: Upgrading is an I/O intensive operation, and is limited to processing a
  13. single shard per node at a time. It also is not allowed to run at the same
  14. time as optimize.
  15. This call will block until the upgrade is complete. If the http connection
  16. is lost, the request will continue in the background, and
  17. any new requests will block until the previous upgrade is complete.
  18. [float]
  19. [[upgrade-parameters]]
  20. ==== Request Parameters
  21. The `upgrade` API accepts the following request parameters:
  22. [horizontal]
  23. `only_ancient_segments`:: If true, only very old segments (from a
  24. previous Lucene major release) will be upgraded. While this will do
  25. the minimal work to ensure the next major release of Elasticsearch can
  26. read the segments, it's dangerous because it can leave other very old
  27. segments in sub-optimal formats. Defaults to `false`.
  28. [float]
  29. === Check upgrade status
  30. Use a `GET` request to monitor how much of an index is upgraded. This
  31. can also be used prior to starting an upgrade to identify which
  32. indices you want to upgrade at the same time.
  33. The `ancient` byte values that are returned indicate total bytes of
  34. segments whose version is extremely old (Lucene major version is
  35. different from the current version), showing how much upgrading is
  36. necessary when you run with `only_ancient_segments=true`.
  37. [source,sh]
  38. --------------------------------------------------
  39. curl 'http://localhost:9200/twitter/_upgrade?pretty&human'
  40. --------------------------------------------------
  41. [source,js]
  42. --------------------------------------------------
  43. {
  44. "size": "21gb",
  45. "size_in_bytes": "21000000000",
  46. "size_to_upgrade": "10gb",
  47. "size_to_upgrade_in_bytes": "10000000000"
  48. "size_to_upgrade_ancient": "1gb",
  49. "size_to_upgrade_ancient_in_bytes": "1000000000"
  50. "indices": {
  51. "twitter": {
  52. "size": "21gb",
  53. "size_in_bytes": "21000000000",
  54. "size_to_upgrade": "10gb",
  55. "size_to_upgrade_in_bytes": "10000000000"
  56. "size_to_upgrade_ancient": "1gb",
  57. "size_to_upgrade_ancient_in_bytes": "1000000000"
  58. }
  59. }
  60. }
  61. --------------------------------------------------
  62. The level of details in the upgrade status command can be controlled by
  63. setting `level` parameter to `cluster`, `index` (default) or `shard` levels.
  64. For example, you can run the upgrade status command with `level=shard` to
  65. get detailed upgrade information of each individual shard.