reindex_upgrade.asciidoc 4.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140
  1. [[reindex-upgrade]]
  2. == Reindex before upgrading
  3. {es} can read indices created in the previous major version. If you
  4. have indices created in 5.x or before, you must reindex or delete them
  5. before upgrading to {version}. {es} nodes will fail to start if
  6. incompatible indices are present. Snapshots of 5.x or earlier indices cannot be
  7. restored to a 7.x cluster even if they were created by a 6.x cluster.
  8. You have two options for reindexing old indices:
  9. * <<reindex-upgrade-inplace, Reindex in place>> on your 6.x cluster before upgrading.
  10. * Create a new {version} cluster and <<reindex-upgrade-remote, Reindex from remote>>.
  11. This enables you to reindex indices that reside on clusters running any version of {es}.
  12. .Upgrading time-based indices
  13. *******************************************
  14. If you use time-based indices, you likely won't need to carry
  15. pre-6.x indices forward to {version}. Data in time-based indices
  16. generally becomes less useful as time passes and are
  17. deleted as they age past your retention period.
  18. Unless you have an unusually long retention period, you can just
  19. wait to upgrade to 6.x until all of your pre-6.x indices have
  20. been deleted.
  21. *******************************************
  22. [[reindex-upgrade-inplace]]
  23. === Reindex in place
  24. You can use the Upgrade Assistant in {kib} 6.7 to automatically reindex 5.x
  25. indices you need to carry forward to {version}.
  26. To manually reindex your old indices in place:
  27. . Create an index with 7.x compatible mappings.
  28. . Set the `refresh_interval` to `-1` and the `number_of_replicas` to `0` for
  29. efficient reindexing.
  30. . Use the <<docs-reindex,`reindex` API>> to copy documents from the
  31. 5.x index into the new index. You can use a script to perform any necessary
  32. modifications to the document data and metadata during reindexing.
  33. . Reset the `refresh_interval` and `number_of_replicas` to the values
  34. used in the old index.
  35. . Wait for the index status to change to `green`.
  36. . In a single <<indices-aliases,update aliases>> request:
  37. .. Delete the old index.
  38. .. Add an alias with the old index name to the new index.
  39. .. Add any aliases that existed on the old index to the new index.
  40. [[reindex-upgrade-remote]]
  41. === Reindex from a remote cluster
  42. You can use <<reindex-from-remote,reindex from remote>> to migrate indices from
  43. your old cluster to a new {version} cluster. This enables you move to {version}
  44. from a pre-6.7 cluster without interrupting service.
  45. [WARNING]
  46. =============================================
  47. {es} provides backwards compatibility support that enables
  48. indices from the previous major version to be upgraded to the
  49. current major version. Skipping a major version means that you must
  50. resolve any backward compatibility issues yourself.
  51. =============================================
  52. To migrate your indices:
  53. . Set up a new {version} cluster and add the existing cluster to the
  54. `reindex.remote.whitelist` in `elasticsearch.yml`.
  55. +
  56. --
  57. [source,yaml]
  58. --------------------------------------------------
  59. reindex.remote.whitelist: oldhost:9200
  60. --------------------------------------------------
  61. [NOTE]
  62. =============================================
  63. The new cluster doesn't have to start fully-scaled out. As you migrate
  64. indices and shift the load to the new cluster, you can add nodes to the new
  65. cluster and remove nodes from the old one.
  66. =============================================
  67. --
  68. . For each index that you need to migrate to the new cluster:
  69. .. Create an index the appropriate mappings and settings. Set the
  70. `refresh_interval` to `-1` and set `number_of_replicas` to `0` for
  71. faster reindexing.
  72. .. Use the <<docs-reindex,`reindex` API>> to pull documents from the
  73. remote index into the new {version} index:
  74. +
  75. --
  76. [source,js]
  77. --------------------------------------------------
  78. POST _reindex
  79. {
  80. "source": {
  81. "remote": {
  82. "host": "http://oldhost:9200",
  83. "username": "user",
  84. "password": "pass"
  85. },
  86. "index": "source",
  87. "query": {
  88. "match": {
  89. "test": "data"
  90. }
  91. }
  92. },
  93. "dest": {
  94. "index": "dest"
  95. }
  96. }
  97. --------------------------------------------------
  98. // CONSOLE
  99. // TEST[setup:host]
  100. // TEST[s/^/PUT source\n/]
  101. // TEST[s/oldhost:9200",/\${host}"/]
  102. // TEST[s/"username": "user",//]
  103. // TEST[s/"password": "pass"//]
  104. If you run the reindex job in the background by setting `wait_for_completion`
  105. to `false`, the reindex request returns a `task_id` you can use to
  106. monitor progress of the reindex job with the <<tasks,task API>>:
  107. `GET _tasks/TASK_ID`.
  108. --
  109. .. When the reindex job completes, set the `refresh_interval` and
  110. `number_of_replicas` to the desired values (the default settings are
  111. `30s` and `1`).
  112. .. Once reindexing is complete and the status of the new index is `green`,
  113. you can delete the old index.