cluster_restart.asciidoc 4.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131
  1. [[restart-upgrade]]
  2. == Full cluster restart upgrade
  3. A full cluster restart upgrade requires that you shut all nodes in the cluster
  4. down, upgrade them, and restart the cluster. A full cluster restart was required
  5. when upgrading to major versions prior to 6.x. Elasticsearch 6.x supports
  6. <<rolling-upgrades, rolling upgrades>> from *Elasticsearch 5.6*. Upgrading to
  7. 6.x from earlier versions requires a full cluster restart. See the
  8. <<upgrade-paths,Upgrade paths table>> to verify the type of upgrade you need
  9. to perform.
  10. To perform a full cluster restart upgrade:
  11. . *Disable shard allocation.*
  12. +
  13. --
  14. include::disable-shard-alloc.asciidoc[]
  15. --
  16. . *Stop indexing and perform a synced flush.*
  17. +
  18. --
  19. Performing a <<indices-synced-flush, synced-flush>> speeds up shard
  20. recovery.
  21. include::synced-flush.asciidoc[]
  22. --
  23. . *Stop any machine learning jobs that are running.* See
  24. {xpack-ref}/stopping-ml.html[Stopping Machine Learning].
  25. . *Shutdown all nodes.*
  26. +
  27. --
  28. include::shut-down-node.asciidoc[]
  29. --
  30. . *Upgrade all nodes.*
  31. +
  32. --
  33. include::upgrade-node.asciidoc[]
  34. include::set-paths-tip.asciidoc[]
  35. --
  36. . *Upgrade any plugins.*
  37. +
  38. Use the `elasticsearch-plugin` script to install the upgraded version of each
  39. installed Elasticsearch plugin. All plugins must be upgraded when you upgrade
  40. a node.
  41. . *Start each upgraded node.*
  42. +
  43. --
  44. If you have dedicated master nodes, start them first and wait for them to
  45. form a cluster and elect a master before proceeding with your data nodes.
  46. You can check progress by looking at the logs.
  47. As soon as the <<master-election,minimum number of master-eligible nodes>>
  48. have discovered each other, they form a cluster and elect a master. At
  49. that point, you can use <<cat-health,`_cat/health`>> and
  50. <<cat-nodes,`_cat/nodes`>> to monitor nodes joining the cluster:
  51. [source,sh]
  52. --------------------------------------------------
  53. GET _cat/health
  54. GET _cat/nodes
  55. --------------------------------------------------
  56. // CONSOLE
  57. The `status` column returned by `_cat/health` shows the health of each node
  58. in the cluster: `red`, `yellow`, or `green`.
  59. --
  60. . *Wait for all nodes to join the cluster and report a status of yellow.*
  61. +
  62. --
  63. When a node joins the cluster, it begins to recover any primary shards that
  64. are stored locally. The <<cat-health,`_cat/health`>> API initially reports
  65. a `status` of `red`, indicating that not all primary shards have been allocated.
  66. Once a node recovers its local shards, the cluster `status` switches to `yellow`,
  67. indicating that all primary shards have been recovered, but not all replica
  68. shards are allocated. This is to be expected because you have not yet
  69. reenabled allocation. Delaying the allocation of replicas until all nodes
  70. are `yellow` allows the master to allocate replicas to nodes that
  71. already have local shard copies.
  72. --
  73. . *Reenable allocation.*
  74. +
  75. --
  76. When all nodes have joined the cluster and recovered their primary shards,
  77. reenable allocation.
  78. [source,js]
  79. ------------------------------------------------------
  80. PUT _cluster/settings
  81. {
  82. "transient": {
  83. "cluster.routing.allocation.enable": "all"
  84. }
  85. }
  86. ------------------------------------------------------
  87. // CONSOLE
  88. NOTE: Because <<_precedence_of_settings, transient
  89. settings take precedence over persistent settings>>, this overrides the
  90. persistent setting used to disable shard allocation in the first step. If you
  91. don't explicitly reenable shard allocation after a full cluster restart, the
  92. persistent setting is used and shard allocation remains disabled.
  93. Once allocation is reenabled, the cluster starts allocating replica shards to
  94. the data nodes. At this point it is safe to resume indexing and searching,
  95. but your cluster will recover more quickly if you can wait until all primary
  96. and replica shards have been successfully allocated and the status of all nodes
  97. is `green`.
  98. You can monitor progress with the <<cat-health,`_cat/health`>> and
  99. <<cat-recovery,`_cat/recovery`>> APIs:
  100. [source,sh]
  101. --------------------------------------------------
  102. GET _cat/health
  103. GET _cat/recovery
  104. --------------------------------------------------
  105. // CONSOLE
  106. --
  107. . *Restart machine learning jobs.*