1
0

delayed.asciidoc 4.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107
  1. [[delayed-allocation]]
  2. === Delaying allocation when a node leaves
  3. When a node leaves the cluster for whatever reason, intentional or otherwise,
  4. the master reacts by:
  5. * Promoting a replica shard to primary to replace any primaries that were on the node.
  6. * Allocating replica shards to replace the missing replicas (assuming there are enough nodes).
  7. * Rebalancing shards evenly across the remaining nodes.
  8. These actions are intended to protect the cluster against data loss by
  9. ensuring that every shard is fully replicated as soon as possible.
  10. Even though we throttle concurrent recoveries both at the
  11. <<recovery,node level>> and at the <<shards-allocation,cluster level>>, this
  12. ``shard-shuffle'' can still put a lot of extra load on the cluster which
  13. may not be necessary if the missing node is likely to return soon. Imagine
  14. this scenario:
  15. * Node 5 loses network connectivity.
  16. * The master promotes a replica shard to primary for each primary that was on Node 5.
  17. * The master allocates new replicas to other nodes in the cluster.
  18. * Each new replica makes an entire copy of the primary shard across the network.
  19. * More shards are moved to different nodes to rebalance the cluster.
  20. * Node 5 returns after a few minutes.
  21. * The master rebalances the cluster by allocating shards to Node 5.
  22. If the master had just waited for a few minutes, then the missing shards could
  23. have been re-allocated to Node 5 with the minimum of network traffic. This
  24. process would be even quicker for idle shards (shards not receiving indexing
  25. requests) which have been automatically <<indices-synced-flush,sync-flushed>>.
  26. The allocation of replica shards which become unassigned because a node has
  27. left can be delayed with the `index.unassigned.node_left.delayed_timeout`
  28. dynamic setting, which defaults to `1m`.
  29. This setting can be updated on a live index (or on all indices):
  30. [source,js]
  31. ------------------------------
  32. PUT _all/_settings
  33. {
  34. "settings": {
  35. "index.unassigned.node_left.delayed_timeout": "5m"
  36. }
  37. }
  38. ------------------------------
  39. // CONSOLE
  40. // TEST[s/^/PUT test\n/]
  41. With delayed allocation enabled, the above scenario changes to look like this:
  42. * Node 5 loses network connectivity.
  43. * The master promotes a replica shard to primary for each primary that was on Node 5.
  44. * The master logs a message that allocation of unassigned shards has been delayed, and for how long.
  45. * The cluster remains yellow because there are unassigned replica shards.
  46. * Node 5 returns after a few minutes, before the `timeout` expires.
  47. * The missing replicas are re-allocated to Node 5 (and sync-flushed shards recover almost immediately).
  48. NOTE: This setting will not affect the promotion of replicas to primaries, nor
  49. will it affect the assignment of replicas that have not been assigned
  50. previously. In particular, delayed allocation does not come into effect after a full cluster restart.
  51. Also, in case of a master failover situation, elapsed delay time is forgotten
  52. (i.e. reset to the full initial delay).
  53. ==== Cancellation of shard relocation
  54. If delayed allocation times out, the master assigns the missing shards to
  55. another node which will start recovery. If the missing node rejoins the
  56. cluster, and its shards still have the same sync-id as the primary, shard
  57. relocation will be cancelled and the synced shard will be used for recovery
  58. instead.
  59. For this reason, the default `timeout` is set to just one minute: even if shard
  60. relocation begins, cancelling recovery in favour of the synced shard is cheap.
  61. ==== Monitoring delayed unassigned shards
  62. The number of shards whose allocation has been delayed by this timeout setting
  63. can be viewed with the <<cluster-health,cluster health API>>:
  64. [source,js]
  65. ------------------------------
  66. GET _cluster/health <1>
  67. ------------------------------
  68. // CONSOLE
  69. <1> This request will return a `delayed_unassigned_shards` value.
  70. ==== Removing a node permanently
  71. If a node is not going to return and you would like Elasticsearch to allocate
  72. the missing shards immediately, just update the timeout to zero:
  73. [source,js]
  74. ------------------------------
  75. PUT _all/_settings
  76. {
  77. "settings": {
  78. "index.unassigned.node_left.delayed_timeout": "0"
  79. }
  80. }
  81. ------------------------------
  82. // CONSOLE
  83. // TEST[s/^/PUT test\n/]
  84. You can reset the timeout as soon as the missing shards have started to recover.