1
0

set-upgrade-mode.asciidoc 3.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100
  1. [role="xpack"]
  2. [testenv="platinum"]
  3. [[ml-set-upgrade-mode]]
  4. = Set upgrade mode API
  5. ++++
  6. <titleabbrev>Set upgrade mode</titleabbrev>
  7. ++++
  8. Sets a cluster wide upgrade_mode setting that prepares {ml} indices for an
  9. upgrade.
  10. [[ml-set-upgrade-mode-request]]
  11. == {api-request-title}
  12. //////////////////////////
  13. [source,console]
  14. --------------------------------------------------
  15. POST /_ml/set_upgrade_mode?enabled=false&timeout=10m
  16. --------------------------------------------------
  17. // TEARDOWN
  18. //////////////////////////
  19. `POST _ml/set_upgrade_mode`
  20. [[ml-set-upgrade-mode-prereqs]]
  21. == {api-prereq-title}
  22. * If the {es} {security-features} are enabled, you must have `manage_ml` or
  23. `manage` cluster privileges to use this API. See
  24. <<security-privileges>> and {ml-docs-setup-privileges}.
  25. [[ml-set-upgrade-mode-desc]]
  26. == {api-description-title}
  27. When upgrading your cluster, in some circumstances you must restart your nodes and
  28. reindex your {ml} indices. In those circumstances, there must be no {ml} jobs running.
  29. You can close the {ml} jobs, do the upgrade, then open all the jobs again.
  30. Alternatively, you can use this API to temporarily halt tasks associated
  31. with the jobs and {dfeeds} and prevent new jobs from opening. You can also use this
  32. API during upgrades that do not require you to reindex your {ml} indices,
  33. though stopping jobs is not a requirement in that case.
  34. For more information, see {stack-ref}/upgrading-elastic-stack.html[Upgrading the {stack}].
  35. When `enabled=true` this API temporarily halts all job and {dfeed} tasks and
  36. prohibits new job and {dfeed} tasks from starting.
  37. Subsequently, you can call the API with the enabled parameter set to false,
  38. which causes {ml} jobs and {dfeeds} to return to their desired states.
  39. You can see the current value for the `upgrade_mode` setting by using the
  40. <<get-ml-info,get {ml} info API>>.
  41. IMPORTANT: No new {ml} jobs can be opened while the `upgrade_mode` setting is
  42. `true`.
  43. [[ml-set-upgrade-mode-query-parms]]
  44. == {api-query-parms-title}
  45. `enabled`::
  46. (Optional, boolean) When `true`, this enables `upgrade_mode`. Defaults to
  47. `false`.
  48. `timeout`::
  49. (Optional, time) The time to wait for the request to be completed. The default
  50. value is 30 seconds.
  51. [[ml-set-upgrade-mode-example]]
  52. == {api-examples-title}
  53. The following example enables `upgrade_mode` for the cluster:
  54. [source,console]
  55. --------------------------------------------------
  56. POST _ml/set_upgrade_mode?enabled=true&timeout=10m
  57. --------------------------------------------------
  58. When the call is successful, an acknowledged response is returned. For example:
  59. [source,console-result]
  60. ----
  61. {
  62. "acknowledged": true
  63. }
  64. ----
  65. The acknowledged response will only be returned once all {ml} jobs and {dfeeds} have
  66. finished writing to the {ml} internal indices. This means it is safe to reindex those
  67. internal indices without causing failures. You must wait for the acknowledged
  68. response before reindexing to ensure that all writes are completed.
  69. When the upgrade is complete, you must set `upgrade_mode` to `false` for
  70. {ml} jobs to start running again. For example:
  71. [source,console]
  72. --------------------------------------------------
  73. POST _ml/set_upgrade_mode?enabled=false&timeout=10m
  74. --------------------------------------------------